LIVRO ENGENHARIA DE SOFTWARE FUNDAMENTOS, MÉTODOS E PADRÕES CAPÍTULO ATIVIDADES, PAG. 138 A 150

Tamanho: px

Começar a partir da página:

Download "LIVRO ENGENHARIA DE SOFTWARE FUNDAMENTOS, MÉTODOS E PADRÕES CAPÍTULO ATIVIDADES, PAG. 138 A 150"

Ana Vitória Caires Brandt
8 Há anos
Visualizações:

1 LIVRO ENGENHARIA DE SOFTWARE FUNDAMENTOS, MÉTODOS E PADRÕES WILSON PADUA PAULA FILHO CAPÍTULO ATIVIDADES, PAG. 138 A 150 1

2 ANÁLISE ESTRUTURAL IDENTIFICAR AS CLASSES ORGANIZAR AS CLASSES IDENTIFICAR RELACIONAMENTOS IDENTIFICAR ATRIBUTOS/HERANÇAS 2

3 ATIVIDADES VISÃO GERAL Mapa das Atividades Identificação das Classes Organização das Classes Modelo de Análise de Sw Visão Lógica Identificação dos Atributos e Heranças Identificação dos Relacionamento Realização dos Casos de Uso Modelo de Análise de Sw Visão de Caso de Uso Revisão da Análise Cadastro de Requisito de Sw Itens de Análise Atividades e artefatos do fluxo de Análise 3

Relacionamento Realização dos Casos de Uso Modelo de Análise de Sw Visão de Caso de Uso Revisão

4 ATIVIDADES VISÃO GERAL A análise tem inicio pela "Identificação das Classes", na qual são analisados os fluxos dos casos de uso e outros documentos relevantes em relação ao produto desejado. Prossegue com a "Organização das Classes", que organiza as classes em pacotes lógicos (agrupamentos de classes correlatas), e atribui lhes os valores de entidade, fronteira e controle, dependendo do papel que desempenham no modelo. A"Identificação dos relacionamentos" determina os relacionamentos de vários tipos que podem existir entre os objetos das classes identificadas. Todas estas atividades alimentam a visão lógica do Modelo de Análise (MA), que contém as especificações e diagramas de classes. 4

Prossegue com a "Organização das Classes", que organiza as classes em pacotes lógicos (agrupamentos de classes correlatas), e atribui lhes os valores de entidade, fronteira

5 ATIVIDADES VISÃO GERAL Em seguida, a "Identificação dos Atributos e Heranças" levantaos atributos de análise, isto é, propriedades que fazem parte do conceito expresso pela classe. Esta informação também vai para a visão lógica. Em paralelo, a "Realização dos casos de uso" verifica os fluxos dos casos de uso, representando os através de diagramas de interação. Esta informação vai para a visão de casos de uso do Modelo de Análise e serve também para determinar a amarração entre as classes de análise e os requisitos, registrando se esta informação no Cadastro dos Requisitos (CR). Por final, a "Revisão da análise" valida o esforço de Análise e o correspondente esforço de Requisitos. 5

Em paralelo, a "Realização dos casos de uso" verifica os fluxos dos casos de uso, representando os através de diagramas de interação.

6 IDENTIFICAR AS CLASSES 6

7 ATIVIDADE IDENTIFICAR AS CLASSES Tarefa para identificação das classes chaves, nada mais são que as classes iniciais do modelo. Uma das técnica mais usada, consiste em localizar os substantivos existentes nos fluxos dos casos de uso e outros requisitos do produto, subtendendo substantivo como: Qual é o substantivo que define a palavra chave? o É a palavra com que se denomina um ser ou um objeto, ou uma ação, como uma qualidade, estado; considerados separados dos seres ou objetos a que pertencem. Fonte: pt.wiktionary.org/wiki/substantivo 7

produto, subtendendo substantivo como: Qual é o substantivo que define a palavra chave?

8 ATIVIDADE IDENTIFICAR AS CLASSES Devemos observar os seguintes detalhes, na pesquisa dos substantivos: Eliminar aspectos de implementação e informações irrelevantes aos procedimentos do produto; Resolver ambiguidades, como: incerteza, insegurança da linguagem; Considerar locuções verbais (verbos), equivalentes a substantivos; Considerar que substantivos podem não resultar em classes, mas em objetos, relacionamentos ou atributos de classes. Permanecer no nível lógico, não incluindo detalhes de interfaces, arquivos, estruturas de dados etc.; Permanecer dentro do escopo do produto, evitando classes que não se conectam com os procedimentos deste. 8

substantivos; Considerar que substantivos podem não resultar em classes, mas em objetos, relacionamentos ou atributos de classes.

9 ATIVIDADE IDENTIFICAR AS CLASSES As responsabilidades representam o conhecimento e ações que possibilitam às classes cumprir seu papel nos casos de uso. As colaborações representam outras classes que colaboram para o cumprimento das responsabilidades das classes já descobertas. Uma boa prática e técnica de levantamento das responsabilidades e colaborações é a utilização baseada nos cartões CRC. 9

As colaborações representam outras classes que colaboram para o cumprimento das responsabilidades

10 ATIVIDADE IDENTIFICAR AS CLASSES Os objetos que não forem consideradas como classes devem ser registradas à parte e posteriormente, poderão se transformar em relacionamentos ou atributos. Como um exemplo, temos uma versão inicial do fluxo da Operação de Venda do sistema de informatização de mercearia, que recebe o nome Merci, próximo slide, onde: O nome do produto aparece em negrito eosnomesdosatoresem itálico; Os substantivos simples ou compostos aparecem sublinhados. 10

Como um exemplo, temos uma versão inicial do fluxo da Operação de Venda do sistema de informatização de mercearia, que

11 ATIVIDADE IDENTIFICAR AS CLASSES O caixeiro faz a abertura da venda. O caixeiro registra os itens vendidos, informando a identificação e a quantidade do item. O Merci totaliza a venda para o cliente da mercearia. O caixeiro encerra a venda. O Merci emite o ticket de caixa para o cliente da mercearia. O caixeiro registra a forma de pagamento. O Merci faz a baixa no estoque das mercadorias vendidas. Exemplo de Fluxo de Caso de Uso 11

O Merci totaliza a venda para o cliente da mercearia. O caixeiro encerra a venda.

12 ATIVIDADE IDENTIFICAR AS CLASSES O próximo passo é fazer uma análise das possíveis classes candidatas: Classe Candidata Análise abertura Operação. venda Provável classe. item vendido Provável classe, melhor descrita como Item de Venda. identificação Atributo de Item de Venda. quantidade Atributo de Item de Venda. cliente da mercearia Entidade fora do escopo do produto. ticket de caixa Relatório (entidade de implementação). forma de pagamento Atributo de Venda. baixa Operação. estoque Conjunto das mercadorias cadastradas, sendo uma provável classe. mercadoria Provável classe. 12

quantidade Atributo de Item de Venda. cliente da mercearia Entidade fora do escopo do produto.

13 Provável classes encontradas: PROCESSO DE DESENV. DE SOFT. ATIVIDADE IDENTIFICAR AS CLASSES 13

14 ATIVIDADE ESPECIFICAÇÕES DAS CLASSES Nomear as classes identificadas é um passo importante da análise. Devemos escolher nomes significativos, como substantivos únicos, com ou sem adjetivo, que melhor caracterizem os elementos das classes. Também devemos evitar nomes vagos, assim como nomes reservados da própria metodologia (classe, tipo etc.). A documentação de cada classe que precisará estar inclusa nas especificação, deverá conter: o umadefiniçãoclaraeconcisadaclasse; o uma lista de responsabilidades e colaborações da classe; o uma lista de regras e restrições aplicáveis; o possíveis exemplos. 14

Também devemos evitar nomes vagos, assim como nomes reservados da própria metodologia (classe, tipo etc.).

15 ATIVIDADE ESPECIFICAÇÕES DAS CLASSES Abaixo temos um exemplo de uma Documentação de Classe: Descrição Armazena a informação relativa a um item de uma venda. Responsabilidades: comandar baixa no estoque; calcular impostos; imprimir linha de ticket e da nota fiscal. Colaborações Venda, Mercadoria Regras e restrições: Cada Item de Venda corresponde a uma linha do ticket de caixa e da nota fiscal. Todo Item de Venda deve corresponder a uma mercadoria no estoque. Exemplos: Seis cervejas Boêmia em lata, duas caixas de pregos tamanho 2. 15

Colaborações Venda, Mercadoria Regras e restrições: Cada Item de Venda corresponde a uma linha do ticket de caixa e da nota fiscal.

16 ATIVIDADE IDENTIFICAR AS CLASSES Ao término das atividades de identificação a mesmas deveremos ter: o Identificado as classes iniciais; o Nomes, como as classes definidas, apresentando suas responsabilidades e colaborações; o Anotadas as regras ou restrições sobre as classes; o Registradas as abstrações que não foram aprovadas como classes, mas continuam como candidatas a outros elementos de modelagem. A seguir teremos alguns exemplos das classes iniciais que poderiam ser encontradas na análise do sistema de informatização de mercearia. 16

classes; o Registradas as abstrações que não foram aprovadas como classes, mas continuam como candidatas a outros elementos de modelagem.

17 ATIVIDADE IDENTIFICAR AS CLASSES Classes chaves de um sistema de informatização de mercearia 17

18 AULAS DE APOIO Este arquivo está disponibilizado para estudos e consultas no formato PDF. Alguns estarão disponíveis para impressão, outros, somente para leitura. ou 18

Documentos relacionados

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação: