Академический Документы
Профессиональный Документы
Культура Документы
II
APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS
ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE
Aprovada em:
Comissão Examinadora:
______________________________________________________________________
Prof. Renato de Campos. D. Sc. – UENF
III
AGRADECIMENTOS
IV
SUMÁRIO
CAPÍTULO 1 - Introdução………………………………………………………………...…1
1.1. Contexto.....................................................................................................................1
1.2. Motivação...................................................................................................................2
1.3. Objetivo......................................................................................................................3
1.4. Hipótese.. ..................................................................................................................3
1.5. Estratégia...................................................................................................................3
1.6. Estrutura do trabalho..................................................................................................4
V
CAPÍTULO 5 – Conclusão...........................................................................................101
Referências Bibliográficas.........................................................................................104
VI
LISTA DE FIGURAS
VII
Resumo da dissertação apresentada ao CCT/UENF como parte das exigências para a
obtenção do grau de Mestre em Ciências (M. Sc.) em Engenharia de Produção.
Uma vez definidas de forma genérica para o Processo Unificado, estas atividades serão
exemplificadas através de sua aplicação à metodologia de desenvolvimento de
sistemas da Dataprev, a MDS-OO Dataprev.
VIII
Abstract of Dissertation Submitted to the CCT/UENF as partial fulfillment of the
requirements for the degree of Master of Sciences.
April - 2003
The current market dynamics has been demanding a constant rebuilding of the
organizations’ business processes in order to maintain their competitiveness. This
dynamics also provokes needs for adaptations in the software that give support to such
processes, in other words, the sprouting of new software requirements. However, the
activity of requirements analysis in software development processes is accomplished a
lot of times without a general and strategic vision of the business.
Once defined in a generic way for the Unified Process, these activities will be
exemplified through its application to the systems development methodology of
Dataprev, the MDS-OO Dataprev.
IX
CAPÍTULO 1
Introdução
1.1. Contexto
1.2. Motivação
1.3. Objetivo
Este trabalho busca definir atividades a serem inseridas no UP, ou em qualquer outro
processo de desenvolvimento baseado neste, de forma a sistematizar o levantamento
de requisitos com base em análise de modelos de negócio.
1.4. Hipótese
1.5. Estratégia
2.1. Introdução
Uma primeira definição de engenharia de software foi proposta por Fritz Bauer na
primeira grande conferência (NAUR; RANDELL; BUXTON, 1969) dedicada ao assunto:
Análise do sistema – que define o papel de cada elemento num sistema baseado
em computador determinando o papel que o sistema desempenhará;
7
• Aumento de Reutilização
necessidades dos interessados. Uma arquitetura é composta por vistas que evidenciam
as informações de determinados aspectos do sistema.
Um software é um sistema complexo que pode ser abordado sob mais de um aspecto.
Cada aspecto pode ser observado a partir de uma vista. Cada vista pode ser modelada
por um ou mais tipos de diagramas. A Figura 3 apresenta as cinco vistas estabelecidas
por Kruchten (1995). Segundo Kruchten o uso de múltiplas vistas permite endereçar os
requisitos de vários interessados no sistema: usuários finais, desenvolvedores,
engenheiros de sistemas, e gerentes de projetos entre outros.
Como foi apresentada na seção anterior, a análise de requisitos é uma etapa sempre
presente na fase de definição do software, independentemente do modelo de
engenharia de software adotado.
Paula (2001) diz que a engenharia de requisitos é formada por um conjunto de técnicas
empregadas para levantar, detalhar, documentar, e validar os requisitos de um produto
de software.
No paradigma da orientação a objeto a análise de requisitos tem sido feita com base
num elemento de modelagem da UML chamado de Caso de Uso. Embora existam
algumas heurísticas propostas para identificação de casos de uso, como as
apresentadas em Schneider e Winters (1998), Jacobson et al (1999), e em Lilly (1999),
não existem métodos estabelecidos que tornem esta atividade mais sistemática. Os
casos de uso são geralmente identificados em entrevistas com futuros usuários do
sistema e responsáveis pelo negócio, realizadas por analistas de sistemas.
17
Segundo PRESSMAN (1995) cada método de análise tem uma notação e um ponto de
vista únicos porém todos eles relacionam-se com um conjunto de princípios
fundamentais:
2.5. UML
A UML foi adotada pela OMG (Object Management Group) em 1997 como linguagem
padrão para a modelagem de sistemas orientados a objeto. Ela é uma linguagem para
especificação, visualização, construção, e documentação de artefatos de sistemas de
software, tão bem como para a modelagem de negócios e outros sistemas que não de
software. Ela representa uma coleção das melhores práticas de engenharia que
provaram sucesso na modelagem de sistemas grandes e complexos. (OMG, 2002)
1. Prover aos usuários uma linguagem de modelagem visual de forma que eles
pudessam desenvolver e trocar modelos;
2. Prover mecanismos de extensão e especialização para estender o centro dos
conceitos;
18
Muitos usuários de outros métodos (BOOCH, OMT, FUSION, entre outros) adotaram a
UML. A maioria das ferramentas de modelagem de sistemas têm implementado o
suporte à linguagem, entre elas o Rose da Rational e o Together da Together Soft.
A UML padroniza notação para descrever modelos, mas não padroniza um processo
para produzir aquelas descrições (uma ordem de atividades bem definidas, um conjunto
de artefatos produzidos, e meios de controlar e monitorar o trabalho). A UML pode ser
usada por diversos processos de desenvolvimento distintos, mais ou menos
formalmente especificados.
1- Itens
2- Relacionamentos
3- Diagramas
1- Itens estruturais
2- Itens comportamentais
3- Itens de agrupamentos
4- Itens de anotação
Os outros três itens restantes – classes ativas, componentes e nós – são semelhante a
classes, ou seja, descrevem conjuntos de objetos que compartilham os mesmos
atributos, operações, relacionamentos e semânticas. Porém, esses três são
suficientemente diferentes e necessários para a modelagem de certos aspectos de
sistemas orientados a objetos e, portanto merecem um tratamento especial:
Classes ativas - são classes cujos objetos têm um ou mais processos ou threads
e, portanto, podem iniciar a atividade de controle. Uma classe ativa é semelhante
a uma classe, exceto pelo fato de que seus objetos representam elementos cujo
comportamento é concorrente com o de outros elementos.
Esses sete elementos – classes, interfaces, colaborações, casos de uso, classes ativas,
componentes e nós – são os itens estruturais básicos que se pode incluir em um
modelo da UML. Também existem variações desses sete elementos, como atores,
21
Os pacotes são itens de agrupamento básico, servem para organizar modelos de UML.
Também existem variações, como frameworks, modelos e subsistemas (tipos de
pacotes).
Esse elemento é o único item de anotação básico que se pode incluir em um modelo
de UML. Geralmente são utilizadas para aprimorar os diagramas com restrições ou
comentários que possam ser mais bem expressos por um texto formal ou informal.
Também existem variações desse elemento, como os requisitos (que especificam
determinado comportamento desejado sob uma perspectiva externa ao sistema).
23
1- Dependência
2- Associação
3- Generalização
4- Realização
1- Diagrama de classes
2- Diagrama de objetos
3- Diagrama de casos de uso
4- Diagrama de seqüência
5- Diagrama de colaborações
6- Diagrama de gráficos de estados
7- Diagrama de atividades
8- Diagrama de componentes
9- Diagrama de implantação
Diagrama de caso de uso - exibe um conjunto de caso de uso e atores (um tipo
especial de classe) e seus relacionamentos. Diagramas de caso de uso abrangem a
visão estática de casos de uso do sistema. Esses diagramas são importantes
principalmente para a organização e a modelagem de comportamentos do sistema.
2.5.4. Adornos
Em sua maioria, os elementos da UML têm uma notação gráfica única e direta, que
proporciona uma apresentação visual dos aspectos mais importantes do elemento. Por
exemplo, a notação para uma classe é intencionalmente projetada para ser desenhada
facilmente, pois as classes são os elementos mais comumente encontrados em
sistemas de modelagem orientados a objetos. A notação de classe também expõe os
aspectos mais importantes da classe, ou seja, seu nome, atributos e operações.
Todos os elementos da notação da UML são iniciados com um símbolo básico, ao qual
pode ser acrescentada uma variedade de adornos específicos desse símbolo.
27
Restrições - são regras aplicadas aos modelos UML. Podem ser aplicadas
para apenas um ou para vários elementos do modelo. Por exemplo pode-se
28
2.6.1. Caractéristicas do UP
Centrado em arquitetura:
Iterativo e Incremental:
Por ser iterativo, cada fase percorre todo o conjunto de fluxos de trabalho (workflows).
Por ser incremental, cada iteração atualiza os artefatos gerados nas iterações
anteriores. Cada fase possui uma maior ênfase em determinados fluxos de trabalho. A
Figura 5, conhecida como “Gráfico das Baleias” apresenta a ênfase que é cada em
cada fase.
O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações
iniciais, dedica-se mais tempo aos requisitos. Já nas iterações posteriores, gasta-se
mais tempo com implementação.
2.6.2. Fases
Concepção:
Elaboração:
Construção:
Transição:
2.6.3. Workflows
Modelagem de negócio:
Requisitos:
Objetiva capturar os requisitos que serão atendidos pelo produto de software. Nas fases
de iniciação e elaboração, a ênfase será maior neste workflow de requisitos, pois o
objetivo destas fases é o entendimento e a delimitação do escopo do produto de
software. O Workflow Levantamento de Requisitos aborda as seguintes atividades:
Identificar casos de uso;
Priorizar casos de uso;
36
Análise e Projeto:
Implementação:
Teste:
Implantação:
Objetiva produzir releases do produto e entregá-los aos usuários finais. Isto pode incluir
atividades de beta-teste, migração de dados ou software existente e aceitação formal.
37
Os workflows de apoio foram definidos no RUP (2002) como forma de suprir algumas
das lacunas deixadas pelo UP (JACOBSON;BOOVH;RUMBAUGH,1999). Seu objetivo
é auxiliar a execução dos workflows principais. São eles:
3.1. Introdução
As organizações empresariais são sistemas complexos e como tal podem ser mais
facilmente entendidas e gerenciadas através de modelos que tornem a abstração da
realidade mais tangível. O conceito de ponto de vista sistêmico é o simples
reconhecimento de que qualquer empresa é um sistema composto por partes, cada
uma das quais tendo suas próprias metas. O administrador percebe que ele só pode
alcançar as metas globais da empresa se visualizar todo o sistema, procurar
compreender e medir as inter-relações e integrá-las de modo que capacite a empresa a
buscar suas metas eficientemente (MANCUSO, 1998).
Toda empresa, seja ela pequena ou grande, possui um modelo de empresa, porém, na
maioria dos casos este modelo é precariamente formalizado. O modelo se encontra na
forma de gráficos organizacionais estabelecidos por gerentes, documentação de
procedimentos operacionais, textos de regulamentações, e em muitas outras formas
como banco de dados e arquivos entre outras. Porém, uma parte do modelo permanece
apenas na mente das pessoas envolvidas no sistema, não sendo formalizado e
documentada. Métodos e ferramentas são necessários para capturar, formalizar,
39
De acordo com a teoria do controle, toda vez que um sistema precisa ser controlado ou
analisado, é necessário um modelo. Os modelos também são necessários para as
atividades de tomada de decisão (PETRIE, 1992). Através de modelos de empresa o
tomador de decisão pode ver a empresa com um certo tamanho e velocidade de
entendimento muito maior, permitindo a integração dos componentes da empresa
(VERNADAT, 1996).
Assim como as arquiteturas de software, uma arquitetura de negócio pode ser criada
para analisar o negócio a luz de diferentes aspectos. Uma arquitetura de negócio é
representada por várias vistas e cada uma destas apresentando um conjunto de
informações significativas, suprimindo outras, e portanto facilitando a análise através de
modelos mais simples. A vista mais comum encontrada em arquiteturas de negócio é a
vista de processos de negócio.
Rozenfeld (2001) define processo de negócio como um fenômeno que ocorre dentro
das empresas e compreende um conjunto de atividades realizadas, associadas às
informações que manipulam, utilizando os recursos e a organização da empresa. Forma
40
uma unidade coesa e deve ser focalizado em um tipo de negócio, que normalmente
está direcionado a um determinado mercado/cliente, com fornecedores bem definidos.
As definições dos processos são usadas para entender o negócio, ver ameaças ou
oportunidades, melhorar ou inovar, e servir como base para outros modelos (como para
modelos de sistemas de software que dão suporte ao negócio). (ERIKSSON; HANS-
ERIK; PENKER, 2000)
objetos, e objetos podem ser reutilizados de um modelo para outro, diminuindo o tempo
de modelagem.
3.3.1. OMG
A OMG (2002) em sua publicação “UML Extension for Busines Modeling” descreve
uma extensão da UML para a modelagem de negócios, em termos de seus
mecanismos de extensão. O documento porém não é uma tentativa de descrever
completamente os novos conceitos e notações para a modelagem de negócios. Ele
apenas descreve estereótipos que podem ser usados para adaptar o uso da
UML à modelagem de negócios.
43
3.3.2. MARSHALL
3.3.3. ERIKSSON
Características:
Diagrama de Objetivos
Características:
Um recurso é uma entidade que pode ter um papel na realização de uma certa classe
de tarefas. (VERNADAT, 1996)
–Objetivos
–Entradas
–Saídas
–Fornecedores
–Controles
Os processos mostram as atividades que devem ser realizadas para atingir um objetivo
explícito, através de seus relacionamentos com os recursos que participam do
processo.
O resultado deve ser a criação de diagramas de processos que descrevam pelo menos
os processos centrais do negócio, sendo estes os processos que possuem interações
com o mundo exterior ou que seja crítico para o fornecimento do produto ou serviço do
negócio. Os processos centrais são portanto normalmente orientados ao cliente.
<<Processo>>
nome do processo
• Objetivos: <<Objetivo>>
52
O Diagrama de Linha de Montagem foi introduzido pelo método Astracan e tem sido
usado com sucesso na modelagem de processos, particularmente quando o propósito
da modelagem é a produção de sistemas de informação que dão suporte aos
processos. (ERIKSSON; HANS-ERIK; PENKER, 2000)
O diagrama deve ser lido da esquerda para a direita na seqüência das referências aos
pacotes da linha de montagem.
54
Os objetos nos pacotes de linha de montagem podem ser qualquer recurso mas são
geralmente objetos de informação em sistemas de informação. O diagrama mostra
portanto quais informações são acessadas pelo processo e quais informações este
envia para o sistema de informação. Um pacote pode representar um sistema de
informação inteiro, um subsistema, uma categoria especial de classes, etc.
O diagrama de linha de montagem pode ser usado como técnica para levantamento de
casos de uso do sistema ou sistemas que darão suporte aos processos de negócio.
Para isso, Eriksson orienta que a análise deve começar com os pacotes em um alto
nível de abstração, como os níveis de sistemas ou subsistemas. Uma vez que as
referências iniciais do processo para os sistemas, ou subsistemas, de informação
tenham sido identificadas, passa-se para a identificação das classes daqueles
sistemas, e a mesma análise pode ser então repetida com os pacotes agora definidos
em outro nível mais detalhado. Neste nível mais detalhado as referências também
devem ser mais detalhadas. Uma simples referência no diagrama inicial pode
corresponder a várias referências nos níveis subseqüentes.
A identificação dos casos de uso através desta técnica faz com que os objetivos dos
atores, e conseqüentemente os requisitos do sistema em forma de casos de uso,
estejam alinhados aos objetivos globais do negócio uma vez que são analisados com
base nos processos de negócio e estes por sua vez foram definidos em função dos
objetivos do negócio. (AZEVEDO;CAMPOS, 2002)
A primeira linha foi introduzida pela OMG em 1997 na primeira versão da especificação
da UML e posteriormente aprimorada no RUP. A Segunda linha corresponde às
iniciativas de Marshall(1999) e Eriksson et al (2000).
Já a segunda linha defende que os processos de negócio não são bem representados
pelos casos de uso pois estes servem para representar um domínio fechado
correspondente a determinados requisitos de usuários, e que os processos de negócio
não podem ser vistos simplificadamente como requisitos de clientes.
57
Uma vez que o modelo de caso de uso da UML não representa fluxo de informações
entre os casos de uso, esses não representam processos de negócio eficientemente
pois estes, por definição, devem estar ligados de forma a formar o fluxo de atividades
necessárias ao objetivo do negócio como um todo.
4.1. Introdução
Mas como identificar todos os casos de uso , ou os casos de uso corretos que melhor
suportam o negócio no qual o sistema operará?
- Objetos de negócio que representam coisas que são manipuladas no negócio, como
pedidos, contas, e contratos.
- Objetos e conceitos do mundo real dos quais o sistema precisa manter registros,
como aeronaves, mísseis, e trajetórias.
- Eventos que são ou serão conhecidos, como chegada de aeronave, saída de
aeronave, e intervalo de almoço.
Como foi visto, no UP os requisitos funcionais são descritos através do modelo de caso
de uso UML. Como apresentado no capítulo 2 o modelo de caso de uso é um diagrama
da UML formado por casos de uso, atores, e relacionamentos entre estes itens. A
descrição de um caso de uso é a documentação que especifica o fluxo de eventos entre
atores e o sistema, bem como operações a serem realizadas pelo sistema.
Também será definida a abordagem que cada atividade proposta deve ter nas fases de
Concepção e Elaboração, que como visto anteriormente são as fases onde devem
existir as atividades de análise de requisitos.
entregue ao cliente. Num caso como este a identificação dos estados possíveis
de tal objeto (como pedido solicitado, pedido em verificação de estoque, pedido
em produção, pedido em expedição e pedido entregue) pode facilitar a
identificação dos processos de negócio necessários ao cumprimento das
mudanças de estado do produto. Produto resultante: Diagrama de Estado de
Recurso e Diagramas de Interação de Recursos e de Estados.
A atividade Encontrar Atores e Casos de Uso, já existente no UP, foi atualizada com a
sub-atividade:
Derivar Casos de Uso dos Processos de Negócio: Os casos de uso devem ser
identificados com base nos processos de negócio. Esta atividade deve resultar
em uma Relação de Casos de Uso na qual deve-se associar cada caso de uso
identificado ao processo (ou processos) de negócio a que este atende. Sugere-
se a utilização do Diagrama de Linha de Montagem como base para a realização
desta atividade. A identificação dos casos de uso no Diagrama de Linha de
Montagem se dá através do agrupamento de referências (entre o processo e os
sistemas) de mesma natureza. Produto resultante: Diagrama de Linha de
Montagem com casos de uso identificados.
A atividade Realização de Casos de Uso, já existente no UP, foi atualizada com a sub-
atividade:
Na Elaboração: Deve ser feita uma reavaliação das Classes identificadas com
base nas referências do Diagrama de Linha de Montagem desenvolvido nesta
fase. Através da análise das referências deve-se identificar que classes serão
responsáveis pela realização dos casos de uso identificados no Diagrama de
Linha de Montagem.
69
Muitas metodologias, como a apresentada em Paula (2001), têm sido concebidas com
base no UP. Cada empresa de desenvolvimento de software tem suas particularidades
e buscam portanto desenvolver suas próprias metodologias ou customizar alguma
existente no mercado. A MDS-OO Dataprev é outro exemplo de metodologia que foi
concebida com base no UP e será objeto de aplicação das atividades propostas neste
trabalho.
Um Diagrama de Estados de Recurso pode ser criado para facilitar a determinação dos
processos de negócio quando este se caracteriza por refinamentos de um mesmo
objeto ao longo da cadeia de valor. Por exemplo, considerando um negócio de vendas,
o pedido pode ser abordado como um objeto cujo estado vai sendo alterado (refinado)
ao longo de toda a cadeia de valor, desde a abertura do pedido até a confirmação do
pedido entregue ao cliente. Num caso como este a identificação dos estados possíveis
77
Nesta fase deve-se modelar o comportamento de recursos nos caso em que estes
sofram várias alterações ao longo dos processos de negócio e esta dinâmica de
alterações precisa ser melhor entendida.
Definir apenas os responsáveis por cada processo de negócio, sejam eles unidades
organizacionais ou funções.
Nesta fase deve-se identificar sistemas de software que dão suporte aos processos de
negócio bem como identificar a necessidade de novos sistemas e subsistemas. Utilizar
o Diagrama de Linha de Montagem como recurso de apoio ao desenvolvimento desta
atividade. Deve-se começar com os pacotes em um alto nível de abstração,
representando os sistemas já existentes e a natureza das informações das referências
que estes fazem a cada processo de negócio analisado. Deve-se então fazer uma
primeira avaliação quanto à natureza das informações e as operações necessárias ao
processo e o atendimento destas pelos sistemas existentes, de forma a buscar
identificar tipos de informações e operações que não estão sendo mantidas pelos
sistemas de software disponíveis. Tais necessidades de informação e de operações
devem ser referenciadas a um outro pacote representativo do sistema (ou sistemas) a
ser construído para atender tais requisitos.
79
Esboçar o Modelo dos principais Casos de Uso do Sistema a ser desenvolvido através
de um Modelo de Caso de Uso. No Modelo devem estar identificados os principais
Atores e Casos de Uso bem como uma descrição de cada Caso de Uso.
Os casos de uso podem ser identificados com base nos processos de negócio. Esta
atividade deve resultar em uma Relação de Casos de Uso na qual deve-se associar
cada caso de uso identificado ao processo (ou processos) de negócio a que este
atende. Sugere-se a utilização do Diagrama de Linha de Montagem como base para a
realização desta atividade. A identificação dos casos de uso no Diagrama de Linha de
Montagem se dá através do agrupamento de referências (entre o processo e os
sistemas) de mesma natureza. Nesta fase a atividade deve visar a identificação dos
casos de uso arquiteturalmente significativos. Estes casos de uso representam
funcionalidades num alto nível de abstração. Estes casos de uso servem como base
para a definição da vista lógica da arquitetura de software que os realizará.
Realizar reunião com o Cliente para apresentar e validar o Modelo de Caso de Uso e as
alterações no Modelo de Processo de Negócio, no Glossário e nas Especificações
Suplementares caso tenha havido.
80
Atualizar o Modelo de Casos de Uso com os novos termos definidos nas entrevistas de
definição da Arquitetura do Software.
Orçamento Definido
Entrevistar cliente visando o detalhamento dos Casos de Uso já identificados bem como
a identificação e detalhamento de outros Casos de Uso . Registrar o levantamento num
Registro de Reunião.
Detalhar o fluxo de eventos dos processos que serão abordados na iteração atual.
Definir os papéis (atores) associados aos eventos que ocorrem no fluxo de evento de
cada processo de negócio.
Analisar e atualizar o Modelo de Caso de Uso com base nas novas informações de
requisitos. A atividade visa identificar todos os casos de uso do sistema com base na
análise das referências entre os processos detalhados e os sistemas de software que
os apoiará.
Desenvolver a Realização de Caso de Uso para cada Caso de Uso. Esta realização
deve mostrar as interações realizadas pelos objetos (Classes) necessárias à realização
do caso de uso.
Realizar entrevista com Cliente para validar os modelos de Análise e Projeto. Deve-se
gerar um Registro de Reunião.
relacionamentos.
Definir Iterações
Cronograma Geral
da Construção
Elaborar
Plano de Testes
Plano de Testes
Implementar
Implementar Componentes
Componentes Implementados
Implementar
Banco de Dados
Banco de Dados
Incrementar modelos de
Requerimentos e de
Análise e Projeto
Atualizar Diagramas de
Modelo de Classes Colaboração
Atualizar
Mapa de Navegação Modelo de Classes
Atualizar
Modelos de Estado Mapa de Navegação
Atualizar
Modelo de Dados Modelo de Estado
Modelo de Dados
Versão Instalável
Transição
S
N
Desenvolver / Incrementar
Manual do Sistema
N Iterações Programadas
para Construção Concluídas
S
94
O Plano de Testes deve conter a descrição de todos os testes que serão realizados
durante o projeto, bem como o momento em que acontecerão.
A.3.3.) Implementar
de suas realizações.
Documentar
Notas de Versão
Notas de Versão
Implantar
Instalação do Ambiente Ambiente de Hardware
de Hardware e Software e Software Instalado
Realizar testes no
Avaliação de Teste
Ambiente de Produção
S
Sistema Aprovado?
N Concepção
Avaliar
Manutenção
Elaboração
Construção
realiza). Deve conter uma descrição da plataforma em que foi testada, e como realizar
sua instalação ou o upgrade do sistema anterior à versão. Também deve documentar
os Bugs e limitações conhecidas nos testes e como contorná-los caso estes ainda não
tenham sido solucionados.
A.4.3.) Implantar
Com a inserção das atividades na MDS-OO Dataprev duas vantagens foram de grande
destaque:
Como proposta para trabalhos futuros sugere-se a comparação desta técnica com
demais técnicas de identificação de requisitos.
Referências Bibliográficas
BOOCH, G.; JACOBSON, I.; RUMBAUGH,J. UML - Guia do Usuário. Rio de Janeiro:
Campos, 2000.
ERIKSSON; HANS-ERIK; PENKER, M. Business Modeling with UML. USA: Wiley &
Sons, 2000.
KRUCHTEN, P.B. The 4+1 View Model of Architecture. Piscataway, NJ: IEEE
Software, November 1995.
LILLY, S. Use Case Pitfalls: top 10 problems from Real projects using Use Cases, In:
Proceedings, technology of object oriented languages and systems, 1999.
MDSDataprev
Metodologia de Desenvolvimento de Sistemas
Orientados a Objeto
da Dataprev
Versão 1.0 –
Setembro de 2002
108
Infraestrutura do cliente preparada com hardware e software para receber a instalação do sistema
desenvolvido.
Arquitetura do Software
Avaliação de Teste
Banco de Dados
Componentes Implementados
Componentes Integrados
Cronograma Geral
Diagramas de Colaboração
Diagramas de Seqüência
109
Especificações Suplementares
Nesta atividade é negociada formalmente, pelo Gestor de conta com os Clientes, a prestação do
serviço através de contrato ou aditivo específico. Orçamento e Cronograma Geral podem ser
renegociados nesta atividade, de acordo com a dinâmica do relacionamento do Gestor de conta
com os Clientes. Após a assinatura de contrato ou aditivo, o desenvolvimento se inicia com o
Documento de Ativação do Projeto.
Glossário
Manual do Sistema
Mapa de Navegação
Este artefato deve ser construído para as aplicações Web. É uma representação gráfica da
estrutura hierárquica de navegação das páginas HTML.
Este modelo identifica as funcionalidades que o sistema deverá atender ao ambiente externo. É o
diagrama da UML usado para se identificar como o sistema se comporta em várias situações que
podem ocorrer durante sua operação. Descreve o sistema, seu ambiente, e a relação entre os dois.
Os componentes deste modelo são os atores e os Casos de Uso.
Modelo de Classe
Modelo de Componentes
Modelo de Dados
Modelos de Estado
É a descrição dos possíveis estados de uma classe e a dinâmica de mudança dos estados. É
representado pelo diagrama de Estado da UML.
Notas de Versão
Documento a ser gerado para toda versão liberada para instalação. Consiste numa descrição das
características da versão.
Orçamento
Nesta atividade será feito o orçamento técnico do desenvolvimento do sistema, a ser negociado
pelo gestor da respectiva conta com os Clientes.
Plano de Implantação
Neste documento são relacionadas e programadas todas as tarefas necessárias para implantação
do sistema no ambiente produtivo tais como: povoamento, piloto, processamento paralelo,
treinamento etc.
Plano de Iteração
Descrição dos subdomínios de análise de cada iteração. Um Sistema simples pode ser elaborado
em apenas uma iteração. Porém, para projetos grandes (os que abrangem várias áreas distintas em
um mesmo negócio) pode-se dividir o domínio do sistema em subdomínios e então realizar uma
iteração para cada subdomínio facilitando assim a análise. O planejamento de cada iteração, e
seus respectivos subdomínios, deve estar descrita no Plano de Iteração.
Plano de Teste
É um documento que define todo o planejamento de teste que será realizado no sistema.
111
Registro de Reunião
Toda reunião relativa ao projeto, seja interna ou com clientes, deve ser registrada, anotando-se os
principais pontos discutidos, as resoluções alcançadas e as pendências.
Sistema Implantado
Usuários Treinados
Visão
Em Visão, é definida a visão que os envolvidos têm do produto a ser desenvolvido, em termos
das necessidades e características mais importantes. Por conter uma descrição dos requisitos
centrais pretendidos, ela proporciona a base contratual para requisitos técnicos mais detalhados.
Fluxos de Eventos:
O operador de expedição pesa cada objeto e registra seu peso seu peso;
Fluxo de Eventos:
a) O processo Expedição:
117
d) Detalhamento:
120