Please enable JavaScript.
Coggle requires JavaScript to display documents.
UE 6 Documentar Requisitos Usando Modelos (N2) (O Termo modelo…
UE 6 Documentar Requisitos Usando Modelos (N2)
O Termo modelo
A utilização de modelos facilita a compreensão de informações específicas sobre um determinado fato e suas inter-relações
Um modelo é a representação abstrata de uma realidade existente, ou uma realidade a ser criada
Propriedades de modelos
Representação da realidade
Os modelos retratam uma realidade observadas sobre seus elementos de modelagem
A criação de modelos pode ser descritiva ou prescritiva
Descritivos
O modelo resultante documenta a realidade existente
Prescritivos
O modelo resultante serve de protótipo para uma realidade fictícia
Dependendo da perspectiva, os 2 próprios modelos podem ser descritivos e prescritivos ao mesmo tempo
Redução
Os modelos reduzem a realidade representada
Pode ser diferenciado entre seleção e compressão
Seleção
Apenas aspectos específicos que fazem parte do discurso do sistema são modelados
Compressão
Resumem-se aspectos do conteúdo do sistema
Pragmatismo
Os modelos são construídos para um uso específico e dentro de um contexto especial
Um modelo contém apenas as informações necessárias para sua respectiva finalidade
Os modelos de requisitos são modelos que documentam os requisitos do sistema a ser desenvolvido
Vantagens dos modelos de requisitos
Informação representada por uma imagem é mais rapidamente compreendida e memorizada
Modelos de requisitos permitem a modelagem de uma perspectiva específica dos requisitos
Definição de uma linguagem de modelagem para uma finalidade específica permite estabelecer abstrações relevantes da realidade
Linguagens de modelagem
É definida por sua sintaxe e semântica
Sintaxe
Define os elementos de modelagem a serem utilizados e especifica as combinações válidas entre eles
Semântica
Define o significado dos elementos de modelagem individuais
Linguagens de modelagem conceitual podem ser classificadas como formais, informais e semiformais, dependendo de seu grau de fomalização
Modelos de Requisitos
Modelos conceituais que documentam os requisitos de um sistema são chamados de modelos de requisitos
UML
A UML (Unified Modeling Language) é frequentemente utilizada para construir modelos de requisitos
A linguagem UML consiste em um conjunto de linguagens de modelagem parcialmente complementares, utilizadas especificamente na engenharia de requisitos para modelar os requisitos de um sistema a partir de diferentes perspectivas
Modelos de Metas
Uma técnica de modelagem de metas largamente conhecida e empregada é o uso de árvores E/OU
Documentação de metas usando árvores E/OU
Decomposição "E"
Para satisfazer a meta, todas as metas subordinadas devem ser atingidas
Decomposição "OU"
Para satisfazer a meta, ao menos uma meta subordinada deve ser atendida
Refinar uma meta também é conhecido como decomposição de metas
Metas são muito apropriadas para refinar a visão de um sistema
Um componente essencial da documentação de requisitos é a descrição das relações de refinamento (ou relações de decomposição) entre metas e suas metas subordinadas
Metas podem ser documentadas tanto em linguagem natural quanto na forma de modelos
Uma meta descreve as intenções de uma característica específica do sistema a ser desenvolvido, desejado por um stakeholder
Casos de Uso
Os casos de uso têm por objetivo documentar as funcionalidades de um sistema planejado ou existente a partir da perspectiva do usuário
A abordagem por casos de uso é baseada em duas técnicas de documentação compementares
Diagrama de casos de uso
São modelos de fácil compreensão que documentam as funcionalidades necessárias do ponto de vista da utilização de um dado sistema, as inter-relações entre essas funcionalidades,bem como o contexto do sistema
Elementos típicos de modelagem em diagramas de casos de uso são:
Objetos
Casos de uso
Definidos para o sistema são representados por meio de eclipses
Atores (pessoas ou outros sistemas) no contexto do sistema
Encontram-se fora do limite do sistema e representam pessoas ou sistemas que interagem com o sistema modelado
Se o ator for uma pessoa, pode ser utilizada a figura humana estilizada e recebe o nome do ator e o rótulo <<ator>>
Se o ator for um sistema, tanto pode ser utilizado o retângulo ou uma figura, em conjunto com o rótulo <<sistema>>
Limite do sistema
Dentro do diagrama de casos de uso separam as partes do caso de uso que pertencem ao sistema, das partes que estão fora do limite do sistema
Relações
Relação de estender (extend)
Expressa que uma sequência de interações que faz parte do caso de uso A estende alguma sequência de interações para o caso de uso B em um ponto especificado
Relação de incluir (include)
Uma relação de inclusão de um caso de uso para outro caso de uso indica que a sequência de interações do primeiro caso de uso inclui a sequência de interações do outro caso de uso
Relação entre atores e casos de uso
Se há comunicação entre um caso de uso e um ou mais atores durante a execução de um caso de uso, a comunicação deve ser anotada através de uma relação de comunicação entre os respectivos atores e caso de uso
Generalização
Nesse caso, os casos de uso ou atores "especialistas" herdam as propriedades dos casos de uso ou dos atores "generalistas"
Exemplo: Os atores "mecânico da assistência técnica" e "representante do atendimento ao cliente" podem ser generalizados como o ator "funcionário"
O ator generalista reúne todos os aspectos que os atores têm em comum
Especificação de casos de uso
Especificações de casos de uso complementam a visão de conjunto oferecida pelos diagramas de casos de uso através de uma especificação exata das propriedades essenciais de cada caso de uso
Para esse fim, um template de caso de uso é geralmente preenchido separadamente para cada caso de uso relevante. Tal template apresentará campos como:
2 - Nome
Denominação única do caso de uso
8 - Descrição do caso de uso
Breve descrição do caso de uso
9 - Evento desencadeador ("trigger")
Nome do evento que dispara a execução do caso de uso
10 - Atores
Lista de todos os atores envolvidos neste caso de uso
13 - Resultado
Descrição dos resultados produzidos durante a execução do caso de uso
11 - Pré-condições
Lista de todas as restrições que precisam ser atendidas antes que o caso de uso possa iniciar sua execução
Diferentes tipos de cenários. Cenários descrevem sequências de eventos que conduzem à execução bem sucedida do caso de uso (cenários principais, cenários alternativos) ou descrevem explicitamente como, durante a execução do caso de uso, situações excepcionais devem ser tratadas (cenários de exceção)
1 - Identificação
Identificador único do caso de uso
3 - Autores
Nomes dos autores envolvidos nessa descrição de caso de uso
4 - Prioridade
Importância do caso de uso de acordo com a técnica de priorização aplicada
5 - Criticalidade
Criticalidade do caso de uso, isto é, qual seria o dano causado pela falha do caso de uso
6 - Fonte
Identificação da fonte da qual foi elicitado o caso de uso
7 - Responsável
O stakeholder responsável pelo caso de uso
12 - Pós-condições
Lista de todos os estados em que o sistema pode se encontrar imediatamente após a execução do cenário principal
14 - Cenário principal
Descrição do cenário principal do caso de uso
15 - Cenário alternativos
Descrição dos cenários alternativos do caso de uso, ou lista de eventos desencadeadores de cenários alternativos. Frequentemente. podem ocorrer pós-condições diferentes daquelas descritas no ponto (12)
16 - Cenários de exceção
Descrição dos cenários de execução do caso de uso, ou lista dos eventos desencadeadores de cenários de exceção. Frequentemente, pós-condições diferentes daquelas descritas no ponto (12) podem ocorrer
17 - Qualidades
Referências cruzadas para requisitos de qualidade
3 perspectivas sobre requisitos
Na documentação baseada em modelos, os requisitos para o sistema a ser desenvolvido são modelados por 3 perspectivas sobrepostas
Perspectiva estrutural
Os modelos de entidade-relacionamento e os diagramas de classe UML são típicos exemplos de linguagens de modelagem para a perspectiva estrutural
São documentadas as estruturas de entrada e saída, bem como aspectos estático-estruturais das relações de uso e dependência do sistema no contexto do sistema
Perspectiva funcional
O uso de diagramas de fluxo de dados ou de diagramas de atividade UML (com o fluxo de objetos entre as ações) é frequente
Documenta qual informação do contexto do sistema está sendo manipulada pelo sistema a ser desenvolvido e quais dados estão sendo transmitidos para o contexto do sistema pelo sistema
Perspectiva comportamental
Autômatos finitos e diagramas de estados UML são tipicamente utilizados para a perspectiva comportamental
Documenta-se a integração do sistema no contexto do sistema com base em estados
Certos aspectos dos modelos de uma perspectiva específica podem também ser encontrados em outras perspectivas. As 3 perspectivas, portanto, não são totalmente separadas
Modelagem de Requisitos na Perspectiva Estrutural
A perspectiva estrutural documenta a estrutura de dados, bem como os relacionamentos de uso e de dependência no contexto do sistema
A perspectiva estrutural é tradicionalmente modelada por meio de diagramas de entidade-relacionamento, que documentam a estrutura da realidade com 3 elementos de modelagem
Tipos de entidades
Definem um conjunto de entidades dentro do universo de discurso
Um tipo de entidade abstrai a partir das características concretas dessas entidades e consequentemente classifica um conjunto em entidades uniformes
Tipos de relacionamentos
Classifica o conjunto de relacionamentos uniformes entre tipos de entidades dentro do universo de discurso
Exemplo: O tipo de relacionamento "executa" pode ser definido entre os dois tipos de entidade "piloto" e "voo" para representar relacionamentos "executa" concretos entre pilotos concretos e voos completos
Abstrai a partir de uma característica concreta de um relacionamento e de entidades relacionadas entre si
Atributos
Um atributo define as propriedades de um tipo de entidade ou de um tipo de relacionamento
Cardinalidade
Define o número de instâncias de relacionamento das quais uma entidade pode fazer parte
Se nenhuma cardinalidade está anotada para um tipo de relacionamento específico, assume-se que o valor é 0
Além disso, o número de instâncias (entidades) em que um tipo de entidade participa de um tipo de relacionamento específico pode ser documentado por meio de cardinalidades
Outra abordagem comum para modelar requisitos na perspectiva estruturam são os diagramas de classe UML
Diagrama de classe UML
Um diagrama de classe é composto por um conjunto de classes e suas associações
Os elementos de modelagem mais frequentemente utilizados nesse contexto para diagramas de classe UML são:
Classes
É representada por um retângulo separado por seções
Seções
Superior
Apresenta atributos que são descritos em maiores detalhes pela instância da classe
Inferior
Encontram-se listadas todas as operações que podem ser executadas com as instâncias da classe
Os compartimentos para atributos e/ou métodos podem ser ocultados ou excluídos completamente
Associações (com multiplicidades e papéis)
São representadas por linhas e podem opcionalmente receber nomes
Multiplicidades podem ser anotadas em cada ponta de uma associação
Multiplicidades representam quantas instâncias de uma classe podem ser associadas com um número definido de instâncias de outra classe
Ao anotar papéis opcionais em uma das pontas de uma associação, ou em ambas, o significado das instâncias de uma classe em relação à associação pode ser refinado adicionalmente
Relacionamentos de agregação e de composição
São tipos específicos de associações. Ambos descrevem um relacionamento entre um todo e suas partes constituintes
Uma composição documenta uma associação mais forte do que uma agregação, pois uma parte constituinte de uma composição não pode existir sem o todo
Uma agregação é representada como um losango vazio
Uma composição é representada por um losango preenchido
Relacionamentos de generalização
É um relacionamento entre uma classe mais específica (a subclasse) e uma classe mais geral (a superclasse)
A subclasse em um relacionamento de generalização herda todas as propriedades da superclasse, podendo adaptar e/ou aumentar essas propriedades
Classes e associações em diagramas de classes UML são semelhantes a tipos de entidades e tipos de relacionamentos nos diagramas entidade-relacionamento
Modelos de classes possuem elementos adicionais de modelagem e têm, portanto, maior poder descritivo
Modelagem de Requisitos na Perspectiva Funcional
A modelagem de requisitos na perspectiva funcional está voltada para a transformação de dados de entrada em dados de saída
Diagramas de fluxos de dados são muitas vezes usados como modelos funcionais
A representação gráfica de um sistema e seu contexto é denominada de diagrama de contexto
Os elementos de modelagem em diagramas de fluxo de dados são:
Processos
Fluxo de dados
Repositório de dados
Entidades externas (Fornecedores/consumidores)
UML 2.0
Em UML 2.0, os fluxos de dados podem ser representados através da modelagem explícita de fluxo de objetos em diagramas de atividade
Diagramas de atividade modelam os "nós" de atividade e o fluxo de controle entre esses "nós" de atividade
Os elementos de modelagem essenciais dos diagramas de atividade UML 2.0 são:
Ações
Nós de início e nós de fim
Fluxo de controle
Fluxo de objetos
Reunião (Merge) de fluxos de controle alternativos
Fork (Separação em fluxos concorrentes)
Join (União de fluxos concorrentes)
Elementos de hierarquização
Modelagem de Requisitos na Perspectiva Comportamental
O comportamento dinâmico de um sistema é modelado a partir da perspectiva comportamental
Nesta perspectiva o foco está nos diversos estados em que um sistema pode se encontrar, bem como nos eventos responsáveis por uma transição entre esses estados
Diagramas de Estados UML
Os diagramas UML, que se baseiam em máquinas de estados finito
Utilizam os seguintes elementos de modelagem
Estados
Estado inicial
Estado final
Paralelismo
Oferece máquinas de estados essencialmente baseadas em statecharts
A UML 2 define pontos de entrada e de saída como uma extensão dos statecharts que permitem uma hierarquização adicional de estados
Máquina de estados finitos
Engloba um conjunto de transições que, dependendo do estado atual da máquina são executadas a partir de um determinado evento
Máquinas de Mealy
Os dados de saída dependem do estado atual da máquina e dos dados de entrada
Máquina de Moore
Os dados de saída dependem exclusivamente do estado atual
Statecharts
São um tipo de autômatos baseados em máquinas de estados finitos
São estendidos para suportar a hierarquização de estados
Tem a finalidade de documentar condições de estados de transição e modelar comportamentos concorrentes
O estado inicial recebe a denominação de superestado
Um estado pode ser decomposto em vários autômatos concorrentes
Estado
Define um momento no qual os sistema apresenta um comportamento específico
Espera determinado evento ocorrer para então executar uma transição definida
Transição
É desencadeada por um evento específico que ocorre em um determinado estado
Descreve a mudança de um estado para o próximo
3 tipos de requisitos são documentados de forma independente e utilizados de forma conjunta
Metas descrevem as intenções dos stakeholders
Casos de Uso e cenários documentam sequências de utilização dos sistema.
Requisitos de sistema descrevem detalhadamente funções e qualidades que o sistema a ser desenvolvido deverá implementar ou apresentar
Resumo
Descrições gráficas podem ser compreendidas de maneira mais rápida e melhor do que descrições em linguagem natural
Modelos frequentemente usados
Modelo de Metas
Diagramas de casos de uso
Modelos conceituais para documentar requisitos a partir de 3 perspectivas
Estrutural
Funcional
Comportamental