Apostila-UML

quando dois requisitos não podem ser totalmente satisfeitos, entendendo, na 
maioria das vezes, as implicações das decisões por eles tomadas durante o 
desenvolvimento de requisitos, criando poucas surpresas no momento de entrega do 
sistema. Os usuários passam a compartilhar com o engenheiro de software uma visão dos 
problemas que estão tentando resolver, dos tipos de soluções possíveis e se sentem um 
pouco donos dos produtos gerados pela extração, sentem-se satisfeitos, informados e 
acreditam que o risco é minimizado. Similarmente, os engenheiros e desenvolvedores de 
software que participaram do processo de extração de requisitos têm confiança de que 
estão resolvendo o problema certo e se convencem de que estão resolvendo o problema 
viável sob todos os aspectos, não somente técnicos, mas também humanos. Sabem que os 
usuários irão cooperar se for necessário novos esclarecimentos e que essas interações serão 
mínimas. 
Saídas de um Processo Ruim – o pior resultado de um processo de extração de requisitos 
mal feito é que os desenvolvedores poderão estar resolvendo o problema errado. Mesmo 
que os desenvolvedores estejam resolvendo essencialmente o problema certo, um processo 
de extração ruim pode trazer outras conseqüências negativas. Compradores e usuários 
podem ficar insatisfeitos (acontecem freqüentemente quando os desenvolvedores não 
ouvem os usuários ou tendem a forçar suas próprias visões e interpretações), resultando 
numa participação menos efetiva por parte dos compradores e usuários, resultando em 
respostas menos completas, podendo continuar afetando o projeto durante o 
desenvolvimento e entrega. Os desenvolvedores podem descobrir que há informações 
importantes faltando, o que resulta em encontros adicionais, podem tomar decisões erradas 
devido à falta de entendimento das reais necessidades. Os requisitos podem mudar 
freqüentemente, resultando em demoras ou esforços desperdiçados nas fases de projeto e 
implementação, resultando num custo maior, atraso no planejamento e algumas vezes, 
projetos cancelados. Tudo isso pode resultar numa perda de dinheiro, tanto para a empresa 
a que pertencem os desenvolvedores, como para os compradores, má reputação e perda de 
credibilidade dos desenvolvedores, além de uma queda na confiança dos próprios 
desenvolvedores em si mesmos 
 
 
 
22 
 
Validação 
 
 Nesta fase pretende-se demonstrar que o documento de requisitos produzido 
corresponde, de fato, o sistema que o cliente necessita. 
 À semelhança do que sucede na análise dos requisitos, pretende-se encontrar 
problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida 
com uma especificação completa dos requisitos. 
 A validação é especialmente importante em sistemas de grandes dimensões porque 
muitas vezes são encontrados erros (durante o desenvolvimento ou já depois de o sistema 
estar sendo usado) no documento de requisitos, e esses erros têm repercussões 
proporcionais à dimensão do projeto. Estes tipos de erros traduzem-se em elevados custos 
e necessidade de refazer muito do trabalho que se julgava já concluído. 
 Durante a fase de validação dos requisitos, devem ser verificados (através de 
checklists) os seguintes atributos dos requisitos: 
 Validade: a especificação resulta da análise dos requisitos identificados junto das 
diversas partes interessadas envolvidas. Como tal, requisitos identificados 
individualmente (isto é, junto de cada parte interessada) podem diferir da 
especificação final que se atinge após o cruzamento de informação e é necessário 
que cada cliente compreenda e aceite a especificação final obtida. 
 Consistência: não devem existir conflitos entre os requisitos identificados. 
 Compreensibilidade/Ambigüidade: os requisitos devem poder ser compreendidos 
de forma inequívoca pelas partes interessadas. 
 Completude: todas as funcionalidades pretendidas devem fazer parte da 
especificação do sistema. 
 Realismo: dadas às restrições do projeto (tecnológicas, financeiras e temporais) o 
sistema especificado tem de ser implementável. 
 Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização 
dos requisitos especificados, estes devem ser descritos de modo a que seja possível 
verificar se foram ou não concretizados, isto é, se o sistema final corresponde à 
especificação inicial. 
 Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar 
claramente identificada. Entre outros motivos, isto é importante para facilitar a 
gestão futura dos requisitos. 
 
 
 
23 
 
 Conformidade com normas: para além dos aspectos funcionais dos requisitos, a 
sua especificação deve obedecer às normas usadas ao longo de todo o documento. 
 A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase 
muito importante na engenharia de requisitos e da qual dependem elevados custos a médio 
e longo prazo. 
 Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos 
em validação de requisitos) é bastante falível e regra geral há erros que não são 
encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase 
posterior, já com o documento validado e o projeto em desenvolvimento ou concluído. 
Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma de 
corrigir o erro detectado. 
UML – Linguagem de Modelagem Unificada 
 
A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é 
uma linguagem visual utilizada para modelar sistemas computacionais por meio do 
paradigma de orientação a objetos. Essa linguagem tornou-se, nos últimos anos, a 
linguagem padrão de modelagem de Software adotada internacionalmente pela indústria de 
Engenharia de Software. 
 Deve ficar bem claro, no entanto, que a UML não é uma linguagem de 
programação e sim uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros 
de Software a definir as características do Software, tais como seus requisitos, seu 
comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas 
necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser 
implantado. Todas essas características são definidas por meio da UML antes do Software 
começar a ser realmente desenvolvido. 
 Através da UML podemos modelar um sistema utilizando vários diagramas, nos 
quais podemos destacar dois grandes grupos: 
 Modelagem Estrutural 
o Diagrama de Classes 
o Diagrama de Objetos 
o Diagrama de Componentes 
o Diagrama de Estrutura Composta 
o Diagrama de Pacotes 
 
 
 
24 
o Diagrama de Implantação 
 Modelagem Comportamental (Temporal) 
o Diagrama de Casos de Uso 
o Diagrama de Atividades 
o Diagrama de Transição de Estados 
o Diagrama de Máquina de Estados 
o Diagramas de Interação Geral 
o Diagramas de Interação entre Objetos 
 Diagrama de Sequência 
 Diagrama de Comunicação 
 Diagrama de Tempo 
 Diagrama de Comunicação 
A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são 
conhecidos como "os três amigos". Eles possuem um extenso conhecimento na área de 
modelagem orientado a objetos já que as três mais conceituadas metodologias de 
modelagem Orientada a Objetos foram eles que desenvolveram e, a UML é a junção do 
que havia de melhor nestas três metodologias adicionado novos conceitos e visões da 
linguagem. 
 A UML é o resultado da unificação da linguagem de modelagem de objetos de 3 
métodos líderes do mercado: Booch, Object Modeling Technique (OMT) e Objected-
Oriented Software Engineering (OOSE). Em 1997, a UML v1.1 foi adotada pela OMG 
(Object Management Group) e desde então tornou-se o padrão da indústria de Software 
para a modelagem de objetos e componentes. 
 
 
 
 
25 
 
Um processo para utilizar a UML 
 
A UML contém notações e regras que tornam possível expressar modelos 
orientados a objetos. Mas ela não prescreve como o trabalho