RUP: Casos de Uso, Fases e Arquitetura
Classificado em Tecnologia
Escrito em em 
português com um tamanho de 7,98 KB
CASO DE USO
O caso de uso tem o objetivo de desenvolver o sistema com a necessidade do usuário. Os casos de uso são usados para ter uma visão das funcionalidades e ao mesmo tempo produzir um resultado para o cliente; o caso de uso faz a definição do sistema quando está sendo executado. Os casos de uso são usados para ter um desenvolvimento e implementação eficientes. Os casos de uso são um meio de os usuários não precisarem aprender linguagens complexas para se comunicar com o sistema. Os requisitos são vistos como os casos de uso. Os casos de uso só poderão dar início quando todos os requisitos funcionais forem capturados de forma que os desenvolvedores possam entendê-lo.
ANÁLISE
Na parte da análise, os casos de uso são refinados. Identifica classificadores e papéis destes na realização dos Casos de Uso.
PROJETO
Define a estrutura do sistema em classes e interfaces. No projeto, é usado para a implementação. O modelo do projeto é realizado pelas classes e objetos.
IMPLEMENTAÇÃO
Será criado um modelo de implantação pelos desenvolvedores. Será definida a implantação física do sistema em nós computacionais. Os elementos do modelo de projeto (classes, objetos) serão implementados como componentes. Os componentes são a parte física do sistema que adapta a realização de um conjunto de interfaces às classes (parte lógica).
TESTE
Na fase de testes, é feita uma validação da implementação para verificar se os requisitos conseguiram atender o sistema.
Questões Verdadeiro/Falso sobre RUP e Requisitos
- (F) Para alcançar uma maior produtividade, no Processo Unificado (PU) os requisitos menos arriscados são implementados antes dos requisitos mais arriscados.
- (V) Durante a Análise procura-se estabelecer uma solução para o problema a ser resolvido.
- (V) Requisito pode ser definido como uma condição ou uma capacidade com a qual o sistema deverá estar em conformidade, e ele pode mudar durante o processo de desenvolvimento de um SW.
- (V) Um artefato pode ser um dos seguintes elementos: um documento, um modelo, o código de uma classe.
- (V) Em um ciclo de desenvolvimento de SW típico do PU, para um projeto de tamanho médio, a maior parte do esforço e programação concentram-se na fase de elaboração. F: porque programação é na fase de construção
- (V) Uma passagem pelas quatro fases do RUP produz uma geração do software.
- (V) Um caso de uso representa quem faz o que (interage) com o sistema, preocupando-se com o comportamento interno do sistema.
- (V) Um cenário é a descrição de uma das maneiras pelas quais um caso de uso pode ser realizado.
- (V) Um ator representa qualquer coisa que interage com o sistema, como por exemplo, uma pessoa, um sistema ou um dispositivo de hardware.
- (F) Um ator pode se relacionar com apenas um caso de uso.
- (F) O relacionamento de inclusão indica que um caso de uso terá seu procedimento copiado num local especificado em outro caso de uso, identificado como base. Enquanto que a extensão é um procedimento executado apenas opcionalmente.
- (F) Decomposição Funcional consiste da divisão de um problema em pequenas partes isoladas, ou seja, é a mesma coisa que um caso de uso.
- (F) A arquitetura do RUP é composta por duas dimensões, uma estática representada pelas disciplinas e outra dinâmica representada pelas fases do ciclo de vida de desenvolvimento. (porque está invertida!)
- (F) Dentre as disciplinas do RUP, nenhuma é considerada guarda-chuva.
- (F) O RUP adota um modelo de processo iterativo e incremental. Sendo que em cada iteração é utilizado o modelo clássico em cascata. Contudo, o modelo prototipagem não é usado no RUP.
- (V) No RUP, cada disciplina possui definição de um fluxo de trabalho, uma visão geral da atividade e uma visão geral de artefatos.
CENTRADO NA ARQUITETURA
A arquitetura será construída na fase da elaboração. A arquitetura descreverá os elementos mais importantes. São criadas várias visões que serão geradas a arquitetura. As visões da arquitetura podem ser:
- VISÃO LÓGICA: Usuário Final, Funcionalidade, Pacotes, Subsistemas, Classes
- VISÃO DE PROCESSO: Analistas: comportamento, testes, processos, iterações
- VISÃO DE IMPLEMENTAÇÃO: Programadores: módulos estáticos, camadas, gerenciamento de configurações
- VISÃO DE IMPLANTAÇÃO: Engenharia de Sistemas: topologia, entrega, instalação, comunicação
- VISÃO DE CASO DE USO: chave
A arquitetura é necessária para desenvolver sistemas complexos. É necessário um arquiteto e desenvolvedores. São sistemas que não existem no mundo real, geralmente são únicos e inexistentes. É necessária também no Entendimento do sistema, Organização do desenvolvimento, Estímulo ao reuso. Na arquitetura, tenta tornar sistemas complexos mais compreensíveis, mas existem alguns desafios: comportamento complexo; Ambiente de operação complexo; Tecnologia complexa. Organização do Desenvolvimento: estímulo ao reuso: quando ele é bem aplicado, gera custos mais baixos e tempo mais curtos.
EVOLUÇÃO DO SISTEMA
CASO DE USO X ARQUITETURA
A arquitetura é desenvolvida em iterações durante a elaboração. Abordagem incremental com resultado sendo uma arquitetura estável; Durante a fase de construção, os casos de uso são implementados baseados nos requisitos dos usuários e dos clientes, sendo também influenciados pela arquitetura selecionada na fase de elaboração.
A DESCRIÇÃO DA ARQUITETURA
É basicamente uma extração sobre os modelos do sistema; Apresenta apenas componentes arquiteturalmente significantes; Contém as 5 visões: casos de uso, análise, projeto, implantação e implementação;
- (F) O RUP define papéis e responsabilidades para executar as atividades e produzir os artefatos. Cada papel é responsável por apenas uma disciplina, a fim de evitar sobrecarga de trabalho e, consequentemente, prejudicar a qualidade dos artefatos produzidos.
- (V) O RUP foi desenvolvido de forma parametrizável, característica esta que permite sua adaptação a diferentes tipos de projetos. No entanto, por ser um processo de desenvolvimento extenso e complexo, não é recomendado para construção de software pequenos e convencionais.
- (V) A principal causa de problemas no desenvolvimento de software é a identificação e especificação de requisitos de baixa qualidade.
- (F) Requisitos são todas as necessidades informadas pelo usuário que passam a compor o escopo do produto. Os requisitos funcionais estão relacionados com as respostas do sistema a entradas específicas e o comportamento em determinadas situações.
- (F) Requisitos não funcionais estão ligados a restrições, como “o sistema deve autenticar usuários”.
- (F) Requisitos funcionais podem ser escritos em diferentes níveis de abstração, sendo que o modelo de casos de uso representa apenas requisitos de usuário.
- (V) A fragilidade da descrição de requisitos por meio de linguagem natural pode ser eliminada pela Especificação de Casos de Uso, que inclusive não permite mais a ocorrência de imprecisão na especificação e a consequente interpretação ambígua dos requisitos.
- (V) Requisitos não funcionais não entram em conflito com os funcionais, uma vez que estes estão relacionados com as funções dos sistemas e aqueles com as restrições.
- (V) Os requisitos de domínio estão voltados principalmente à descrição das regras de negócio.
- (V) É recomendado o uso do modelo de casos de uso como um contrato entre o cliente e equipe de desenvolvimento, uma vez que nele estão representados os requisitos funcionais e não funcionais correspondentes e as fronteiras do sistema.