Estudo Prova

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

UML – Modelagem Visual UML é um conjunto de notações dirigidas à 
modelagem de sistemas, usando conceitos de Orientação a Objetos. A 
modelagem visual promove melhor entendimento das exigencies, Projetos 
mais limpos, Manutenção mais fácil de sistemas, Modelos são abstrações 
que retratam a essência de um problema ou estrutura complexa, Somente 
os aspectos relevantes para a solução do problema são considerados. 
Diagramas de Interação 
Diagrama de Sequência: A principal função é indicar a 
funcionalidade da interface do sistema, ou seja, encontrar mais facilmente 
as operações e consultas de sistema 
Diagrama de Comunicação: Basea-se no contexto e na 
familiaridade de um conjunto de objetos. Fixa a atenção em como os 
objetos estão se organizando para efetuar uma tarefa. 
Diagrama de Colaboração: Na troca de mensagens, cada objeto possui 
uma identificação esperada pelos outros objetos 
 
Processo Unificado: É o conjunto de atividades necessárias para 
transformar requisitos do usuário em um sistema de software. 
Direcionado a caso de uso: Um caso de uso é uma porção de 
funcionalidade do sistema que dá ao usuário um resultado de valor. Casos 
de uso capturam ou reúnem requisitos funcionais. Todos os UCs juntos 
resultam no diagrama de casos de uso, que descreve a funcionalidade 
completa do sistema. 
Centrado na Arquitetura: A arquitetura é influenciada por muitos fatores, 
tais como: 
a plataforma de software sobre a qual o sistema vai rodar (sistema 
operacional, sistema gerenciador de banco de dados, protocolos para 
comunicação em 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, classes etc.). considerações de distribuição. sistemas legados. 
requisitos não funcionais (performance, confiabilidade etc.). 
Iterações = passos em um fluxo de trabalho. Incrementos = crescimentos 
do produto. 
Processo Unificado 
FASE DE CONCEPÇÃO: Levantamento de requisites. Organização dos 
requisites. Planejamento dos ciclos iterativos, Casos de Uso. 
FASE DE ELABORAÇÃO: 
 Análise de requisitos e de domínio (Artefatos: Casos de Uso( 
Versão Essencial Expandida, Fluxo Principal, Sequências Alternativas). 
Identificação dos fluxos de entrada e saída de informação Identificação de 
Eventos e Operações de Sistema. Elaboração de Diagramas de Sequência) 
Projeto( Camada de Domínio (Artefatos: Modelagem 
Conceitual( Conceitos, Atributos, Associações) Elaboração de 
Contratos para as Operações e Consultas de Sistema), Camada 
de Interface(Artefatos: Diagramas de Comunicação, Padrões de 
Projeto (Design Patterns), Diagrama de Classes de Projeto – 
DCP). Camada de Persistência(Artefatos: Diagramas de 
Navegação, Projeto Gráfico da Tela Central do sistema, Associar 
cada componente da tela às respectivas operações e consultas 
de sistema, identificadas na etapa de Análise.)). 
FASE DE CONSTRUÇÃO: Geração de código. Testes. 
FASE DE TRANSIÇÃO: Implantação do sistema no ambiente real com dados 
reais. 
Casos de uso essenciais concentram-se em o que os atores fazem, não 
como. Ex.: Essencial: o sistema registra a venda. 
 Breve – apenas uma frase ou parágrafo descrevendo o 
processo principal e típico 
 Expandido – Todos os passos e variações são detalhadamente 
descritos, incluindo pré-condições e pós-condições de sucesso. 
 
Fase De Elaboração 
É a segunda fase do UP cujo objetivo, segundo LARMAN (2008), é iniciar as 
iterações durante as quais a arquitetura central e de alto risco do software 
é programada e testada, a maioria dos requisitos é descoberta e 
estabilizada e os principais riscos são mitigados ou retirados. Segundo 
LARMAN (2008), a análise de domínio representa a investigação a fim de 
se identificar classes conceituais relacionadas com os requisitos da 
iteração corrente, criar um modelo de domínio inicial e modelar atributos 
e associações adequadas. Desta forma, um modelo de domínio ilustra 
importantes conceitos em um domínio 
Expansão De Caso De Uso. 
A expansão dos casos de uso representa a atividade de análise de 
requisitos. A atividade de expansão dos casos de uso consiste em 
documentar a sequência de eventos de um ator (um agente externo) 
usando o sistema para completar, do início ao fim, um determinado 
processo. “quando se está expandindo um caso de uso é preciso proceder 
a um exame detalhado do processo de negócio. Deve-se descrever o caso 
de uso passo a passo: como ele ocorre, como é a interação entre os 
usuários e o sistema. Essa descrição passo a passo é interessante por não 
ser estruturada com desvios, a princípio. Ela se baseia em uma sequencia 
default, ou fluxo principal, na qual se descreve o que acontece quando 
tudo dá certo na interação. Esse fluxo também é chamado de caminho 
feliz pois nele não é necessário dizer o que acontece quando ocorre 
exceções. Depois de descrever o fluxo principal, passa-se uma atividade 
que corresponde a uma das grandes contribuições do caso de uso para 
descrever a interação entre usuário e sistema: analise de forma crítica 
cada passo do caso de uso e procura-se verificar o que poderia dar errado. 
A partir da identificação de uma possível exceção, deve-se construir uma 
descrição de procedimentos para contornar o problema. O caso de uso 
então passa a possuir as chamadas sequências alternativas semelhantes 
aos handlers dos métodos de tratamento de exceções.” 
Operação de Sistema e Consulta 
“operações de sistema são métodos ativados a partir de um evento de 
evento de sistema, ou seja, como resposta a uma ação de um usuário. As 
operações de sistema, por definição indicam um fluxo de informações do 
exterior para o interior do sistema, e , portanto, de alguma forma elas 
alteram as informações gerenciadas pelo sistema. Consultas de sistema 
são métodos correspondentes à simples verificação de informação já 
armazenada. Essa informação pode ser apresentada exatamente como 
está armazenada, ou modificada pela aplicação de funções (por exemplo: 
média, total etc.). No entanto, por definição, uma consulta de sistema não 
deve ser responsável por inserir, remover ou alterar informações 
armazenadas. Pode se definir que as operações e consultas de sistema, em 
conjunto, correspondem à totalidade das funções possíveis do sistema, 
isto é, à funcionalidade efetiva total do sistema.” 
Modelo Conceitual 
o modelo conceitual deve descrever a informação que o sistema vai 
gerenciar. Trata-se de um artefato do domínio do problema e não do 
domínio da solução. Portanto, o modelo conceitual não deve ser 
confundido com a arquitetura do software porque esta, embora 
inicialmente derivada do modelo conceitual, pertence ao domínio da 
solução e, portanto, serve a um objetivo diferente. O modelo conceitual 
também não deve ser confundido com o modelo de dados, pois o modelo 
de dados enfatiza a representação e a organização dos dados 
armazenados, enquanto o modelo conceitual visa a representar a 
compreensão da informação e não da sua representação física. Assim, um 
modelo de dados relacional é apenas uma possível representação física de 
um modelo conceitual mais essencial. 
Elaboração de Contratos 
Na fase de construção dos diagramas de sequencia de sistema, foram 
identificadas as operações e consultas de sistema. Cada operação ou 
consulta desse tipo implica a existência de uma intenção por parte do 
usuário. Essa intenção é capturada pelos contratos de operações de 
sistema e pelos contratos de consulta de sistema, que correspondem à 
modelagem funcional do sistema. Um contrato de operação de sistema 
pode ter três seções: 
a) precondições (opcional); b)pós-condições (obrigatória); c)exceções 
(opcional). Já um contrato para uma consulta de sistema pode ter duas 
seções: a)precondições (opcional); b)resultados (obrigatória). 
As precondições existem nos dois tipos de contratos e devem ser 
cuidadosamente
estabelecidas. Elas complementam o modelo conceitual 
no sentido de definir o que será verdadeiro na estrutura da informação do 
sistema quando a operação ou consulta for executada. Isso significa que 
elas não serão testadas durante a execução, mas algum mecanismo 
externo deverá garantir a sua validade antes de habilitar a execução da 
operação ou consulta de sistema correspondente. 
As pós-condições também devem ser muito precisas. Elas estabelecem o 
quê uma operação de sistema muda na estrutura da informação 
armazenada.