Os vários subprodutos produzidos durante o processo de desenvolvimento de um software, são ditos artefatos de software. Os diagramas (casos de uso, classes, sequência), requisitos e documentos do projeto são artefatos do desenvolvimento do software que ajudam a descrever a função, arquitetura e o design do software. Porém existem outros artefatos que estão relacionados com o processo de desenvolvimento, que podem variar de acordo com o processo adotado, como por exemplo planos de projeto, processos de negócios e avaliações de risco. O código do software, manuais, arquivos executáveis e módulos também são considerados artefatos de software.
Os artefatos são classificados de acordo com a sua função. As etapas do processo de desenvolvimento utiliza artefatos de entrada (gerados nas etapas anteriores) no inicio de cada etapa e produz, ao término, artefatos de saída que serão utilizados nas etapas seguintes. Nesse sentido, os modelos são necessários para padronizar os formatos e melhorar a comunicação entre os elementos presentes nas etapas do processo.
Vamos agora revisar três tipos de diagramas: casos de uso, classes e sequência.
Vamos agora revisar três tipos de diagramas: casos de uso, classes e sequência.
Modelo: diagrama de casos de uso
Diagrama de casos de uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. Descrevem um cenário que mostra as funcionalidades do sistema do ponto de visto do usuário.
O cliente deve ver no diagrama de casos de uso as principais funcionalidades do sistema. O diagrama de Caso de Uso é representado por atores, casos de uso e relacionamentos entre estes elementos.
Você lembra o que significa as anotações <<include>> e <<extend>>?
<<include>> - Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B também será executado. A direção do relacionamento é do caso de uso que está incluindo para o caso de uso incluído.
<<extend>> - Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também. A direção do relacionamento é do caso de uso extensor para o caso de uso estendido.
Você lembra o que significa as anotações <<include>> e <<extend>>?
<<include>> - Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B também será executado. A direção do relacionamento é do caso de uso que está incluindo para o caso de uso incluído.
<<extend>> - Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também. A direção do relacionamento é do caso de uso extensor para o caso de uso estendido.
Modelos: diagrama de classes
Modelos: diagrama de sequências
Vamos praticar com o POSCOMP 2015 - Questão 67
Diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos
Modelos: diagrama de sequências
Diagrama de sequência mostra uma interação, que representa a sequência de mensagens entre instâncias de classes, componentes, subsistemas ou atores. Tempo flui para baixo no diagrama e mostra o fluxo de controle de um participante para outro.
Vamos praticar com o POSCOMP 2015 - Questão 67
A Empresa XYZ tem como missão desenvolver software com um alto padrão de qualidade. A empresa possui entre seus colaboradores uma pessoa responsável por analisar a consistência dos artefatos gerados na atividade de projeto de software, mais precisamente na construção dos diagramas de casos de uso, diagramas de classes e diagramas de sequência. O analista de qualidade recebeu os seguintes diagramas para analisá-los quanto à sua consistência.
Agora vamos aos diagramas!
Agora vamos aos diagramas!
Após análise, o analista de qualidade identificou que, no diagrama de sequência,
(A) o método capturar da classe InterfaceLogin não é consistente com o método apresentado na troca de mensagem.
(B) o objeto Usuario instanciado é órfão de uma classe.
(C) o objeto InterfaceLogin é órfão de uma classe e o método capturar da classe InterfaceLogin não é consistente com o método apresentado na troca de mensagens.
(D) o objeto Users é órfão de uma classe e o método validar da classe Usuarios não é consistente com o método apresentado na troca de mensagens.
(E) o objeto InterfaceLogin é órfão de uma classe e o método logar da classe Usuarios é consistente com o método apresentado na troca de mensagens.
Confira a resposta do nosso Guia do Poscomp 2015!
Por,
Gleyser Guimarães - Integrante do PET Computação
Nenhum comentário :
Postar um comentário