Analise e Projeto de Sistemas
Profa. Eliane Ribeiro
eribeiro@[Link]
Resumo da Aula
Assim como a construção de um prédio, o desenvolvimento
de software requer um planejamento extenso.
A criação de software orientado a objetos envolve etapas
preliminares, independentemente da metodologia adotada.
Coleta de Requisitos:
Entender o problema a ser resolvido e as funcionalidades
necessárias. Esta etapa envolve discussões, brainstorming
e documentação das decisões.
Descrição do Software:
Descrever o software da perspectiva do usuário, definindo
a metodologia de gestão do projeto (Waterfall, Agile, etc.)
e criando protótipos.
Identificação das Classes de Domínio:
Identificar as principais classes de regra de negócio
da aplicação.
Criação dos Diagramas:
Modelar o sistema utilizando representações visuais de
classes, atributos e comportamentos, para o que se utiliza
a UML.
Engenharia de Requisitos
A Engenharia de Requisitos é a ponte entre o projeto e a construção do software,
focando em:
•O contexto do trabalho de software.
•As necessidades específicas que o projeto deve atender.
•As prioridades para a conclusão do trabalho.
•As informações, funções e comportamentos que impactarão o projeto final.
Esta área abrange sete tarefas distintas: Concepção, Levantamento, Elaboração,
Negociação, Especificação, Validação e Gestão. Todas são adaptadas às
necessidades do projeto e algumas ocorrem em paralelo.
Envolvidos (Stakeholders)
Um stakeholder é qualquer pessoa que se beneficia direta ou
indiretamente do sistema. Incluem gerentes, pessoal de marketing,
clientes (internos e externos), usuários, consultores, e engenheiros.
Cada um tem uma visão diferente do sistema, obtém benefícios
distintos e está sujeito a riscos variados.
É crucial diferenciar clientes (quem solicita o software, define
objetivos e coordena recursos financeiros) de usuários (quem
realmente usa o software para atingir um propósito de negócio e
define detalhes operacionais).
Requisitos Não Funcionais (NFR)
São atributos de qualidade, desempenho, segurança ou
restrições gerais do sistema. Frequentemente difíceis de
articular pelos envolvidos, a Função de Qualidade (QFD)
tenta traduzir necessidades não mencionadas em requisitos
de sistema. São listados separadamente na especificação
de requisitos de software.
Levantamento de Requisitos
Combina solução de problemas, elaboração, negociação e
especificação. Envolvidos trabalham colaborativamente
para identificar o problema, propor soluções, negociar
abordagens e especificar requisitos preliminares. As
diretrizes básicas incluem reuniões colaborativas, regras de
participação, agenda formal/informal, um facilitador e um
mecanismo de definições.
Mapeamento de Requisitos:
Casos de Uso e Histórias de Usuário
Após a coleta, os requisitos são mapeados para o design do
software, fornecendo descrições curtas e precisas da funcionalidade
sob a perspectiva do usuário.
Casos de Uso
Documentam os recursos do sistema e precisam de:
•Título: Representa uma funcionalidade distinta (ex: “Criar nova viagem”).
•Ator: Quem utiliza a funcionalidade (ex: Viajante, Comprador). Deve ser o menos
genérico possível.
•Cenário: Explicação detalhada de como o software funciona (ex: “O usuário pode
iniciar a criação de uma nova viagem a partir da tela principal”).
O formato do caso de uso pode variar, mas o importante é focar na funcionalidade
da aplicação, evitando questões técnicas, e ser compreendido por todas as partes
interessadas, incluindo usuários finais.
Histórias de Usuário
São descrições curtas de uma funcionalidade, mais concisas que os casos de uso,
geralmente em uma ou duas frases.
O formato comum é: “Como um <tipo de usuário>, eu quero <algum objetivo>
para que <uma razão/motivo>”.
Ex: “Como viajante eu quero adicionar notas à minhas despesas para que eu possa
identificá-las mais tarde”.
Histórias maiores são chamadas de Épicos, que descrevem um conjunto maior de
funcionalidades e podem ser divididos em histórias de usuário menores.
Ex: “Como um viajante, quero controlar minhas despesas no exterior para não
exceder meu orçamento.”
Iniciativas
Representam coleções de épicos que levam a um objetivo comum.
A hierarquia é: Histórias de Usuário (requisitos curtos) ->
Épicos (grandes corpos de trabalho) -> Iniciativas (coleções de épicos).
Histórias de usuário são usadas para iniciar discussões e são comuns em projetos
ágeis, enquanto descrições de casos de uso são mais vistas em projetos em
cascata.
Ambas não descrevem aspectos técnicos, mas servem como ponto de partida para
a comunicação.
Introdução à UML (Unified Modeling Language)
Antes de aprofundar na UML, é importante notar que as duas primeiras etapas da
análise orientada a objetos (coleta e mapeamento de requisitos) não exigem
ferramentas ou linguagens de design específicas, podendo ser realizadas por
equipes multidisciplinares com ferramentas simples.
A UML é essencial para a comunicação de design, sendo uma linguagem padrão
lançada em 1997. Sua definição é: “Notação gráfica padrão usada para descrever
sistemas orientados a objetos”. A UML fornece um conjunto de diagramas padrões
para descrever a estrutura e o comportamento dos sistemas de software.
Histórico da UML
Com o surgimento das linguagens orientadas a objetos nos anos 90,
a necessidade de um padrão de comunicação tornou-se evidente.
Havia três métodos de modelagem de software (Booch method, OMT
e Objectory), mas a falta de padronização dificultava a comunicação.
A UML foi desenvolvida combinando o melhor desses sistemas,
tornando-se um padrão mundial em 1997 (versão 1.1).
O que é UML?
A UML não é uma linguagem de programação, mas uma notação
gráfica padrão para comunicar, especificar, visualizar, construir e
documentar artefatos de sistemas de software. É amplamente
utilizada na indústria e possui 14 diagramas, divididos em dois
grupos:
•
Diagramas Estruturais:
Representam a estrutura do software (ex: Diagrama de Classes,
Diagrama de Objetos, Diagrama de Componentes, Diagrama de
Estrutura Composta, Diagrama de Pacotes, Diagrama de
Implantações, Diagrama de Perfil).
Diagramas Comportamentais:
Representam o comportamento dinâmico do software (ex: Diagrama
de Casos de Uso, Diagrama de Sequência, Diagrama de
Comunicação, Diagrama de Estados, Diagrama de Atividades,
Diagrama de Interação Geral, Diagrama de Tempo).
Cada diagrama da UML possui um padrão rígido de elementos e é
crucial conhecer a finalidade de cada um. A UML ajuda a quebrar
barreiras entre linguagens de programação, permitindo implementar
o mesmo cenário em diferentes linguagens de forma padronizada.
Exercícios
Coleta de Requisitos:
1. Quais são os maiores desafios na fase de coleta de requisitos em projetos de
software, especialmente quando os stakeholders têm visões divergentes?
2. Como a comunicação eficaz pode mitigar problemas na coleta de requisitos?
Quais técnicas ou ferramentas podem ser utilizadas para melhorar essa
comunicação?
3. Considerando a diferença entre clientes e usuários, como garantir que as
necessidades de ambos sejam adequadamente capturadas e priorizadas
durante a coleta de requisitos?
Requisitos Não Funcionais (NFR):
1. Por que os requisitos não funcionais são frequentemente difíceis
de serem articulados pelos envolvidos? Dê exemplos de NFRs que
podem ser negligenciados e suas consequências.
2. Como a técnica de Função de Qualidade (QFD) pode ser aplicada
na prática para traduzir necessidades implícitas em NFRs claros e
mensuráveis?
Casos de Uso e Histórias de Usuário:
1. Em que cenários um Caso de Uso seria mais apropriado do que uma História de
Usuário, e vice-versa? Qual a principal vantagem de cada um?
2. Como a granularidade (Histórias de Usuário, Épicos, Iniciativas) ajuda no
planejamento e execução de projetos de software, especialmente em
metodologias ágeis?
3. Discuta a importância de evitar jargões técnicos na descrição de Casos de Uso e
Histórias de Usuário. Como isso impacta a colaboração entre equipes
multidisciplinares?
Sobre a UML:
1. Qual a relevância da UML no contexto atual do desenvolvimento de software,
considerando a diversidade de linguagens e frameworks? Ela ainda é
indispensável?
2. Escolha um dos diagramas da UML mencionados (estrutural ou
comportamental) e discuta um cenário prático onde ele seria fundamental para
o entendimento e comunicação de um sistema.
3. Como a UML pode ser utilizada para preencher a lacuna de comunicação entre
desenvolvedores e stakeholders não técnicos?
Reflexão Geral:
1. A frase “Não é comum, mas geralmente acontece...” aparece
repetidamente nos primeiros slides. O que o Prof. Lozano pode
estar querendo transmitir com essa repetição no contexto de
Análise e Projeto de Sistemas?
2. Como a compreensão dos fundamentos da Análise Orientada a
Objetos e da Engenharia de Requisitos pode impactar
positivamente a qualidade e o sucesso de um projeto de
software?