Vis˜ ao Global

Em um primeiro momento, o projetista respons´avel (ou a equipe) deve se preocupar em reunir o maior n´umero de informa¸c˜oes relevantes sobre o SoC com o cliente ou mesmo atrav´es de pesquisas. As informa¸c˜oes contidas no documento devem estar diretamente ligadas a todo e qualquer tipo de requisito, sendo ele funcional ou n˜ao. A ordem em que a captura ´e feita n˜ao tem relevˆancia. O objetivo principal desta etapa ´e detalhar, atrav´es dos requisitos, todas as funcionalidades do SoC que se deseja desenvolver. Uma vez capturadas, as informa¸c˜oes devem estar organizadas de forma ordenada e numerada. Abaixo podemos ver o primeiro documento da Analise de Requisitos, uma lista contendo todos os requisitos capturados e que possuem rela¸c˜ao direta com o projeto do Gerador de Caracteres.

Gerador de Caracteres - Requisitos capturados:

1. O m´odulo deve ser capaz de enviar caracteres para um “display” de v´ıdeo;

2. O m´odulo deve ser capaz de converter um c´odigo ASCII para o padr˜ao de visualiza¸c˜ao do “display” de v´ıdeo;

3. O “display” dever´a receber dados dos caracteres da linha de forma serial; 4. O m´odulo deve permitir a visualiza¸c˜ao de caracteres mai´usculos e min´usculos;

5. O m´odulo deve permitir a visualiza¸c˜ao de espa¸cos (inclu´ıdo ap´os a revis˜ao); 6. Os caracteres dever˜ao ser armazenados em mem´oria;

7. Os caracteres ser˜ao representados atrav´es do c´odigo ASCII;

8. Cada endere¸co de mem´oria equivaler´a a um c´odigo ASCII em particular; 9. O m´odulo deve ser capaz de ler um caractere armazenado mem´oria;

10. O “display” ou monitor ter´a a resolu¸c˜ao padr˜ao de uma imagem no formato QCIF(176Cx144L) - Detalhado no padr˜ao H.261 de compress˜ao de v´ıdeo;

11. O mem´oria deve ser capaz de armazenar uma tela completa;

12. O m´odulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do “display”;

13. O m´odulo dever´a controlar os sinais de v´ıdeo necess´arios para o funcionamento do “display”;

14. O m´odulo dever´a gerar o sinal de sincronismo horizontal (inclu´ıdo ap´os a revis˜ao); 15. O m´odulo dever´a gerar o sinal de sincronismo vertical (inclu´ıdo ap´os a revis˜ao); 16. O m´odulo dever´a gerar o sinal de retra¸co horizontal (inclu´ıdo ap´os a revis˜ao); 17. O m´odulo dever´a gerar o sinal de retra¸co vertical (inclu´ıdo ap´os a revis˜ao);

18. O m´odulo dever´a formar uma linha de caracteres por vez (inclu´ıdo ap´os a revis˜ao); 19. O m´odulo dever´a ser capaz de transformar um c´odigo ASCII em uma matriz de

pontos (pixels) 8x8 (inclu´ıdo ap´os a revis˜ao);

No primeiro documento obtido nem sempre se consegue alcan¸car o objetivo, que ´e descrever todas as funcionalidades e restri¸c˜oes. Ap´os uma r´apida revis˜ao foi poss´ıvel identificar que alguns requisitos n˜ao haviam sido abordados. Esses requisitos foram inclu´ıdos apenas para conhecimento do leitor, mesmo sendo uma informa¸c˜ao desnecess´aria ao projeto. Os requisitos relevantes devem constar nesta lista, mesmo que o projetista somente os identifique algumas etapas adiante.

A tarefa ap´os a defini¸c˜ao da lista de requisitos ´e a de classifica¸c˜ao. Todo e qualquer requisito foi classificado como requisito funcional ou n˜ao-funcional. A se¸c˜ao 3.3.1 descreve as informa¸c˜oes necess´arias para auxiliar o projetista durante esta tarefa.

O segundo documento ´e praticamente a mesma lista apresentada no primeiro, por´em com a adi¸c˜ao de um campo contendo a classifica¸c˜ao de cada requisito (FIG. 4.1).

Gerador de Caracteres - Classifica¸c˜ao dos Requisitos

Figura 4.1: Classifica¸c˜ao dos Requisitos em funcionais e n˜ao-funcionais

Ap´os a classifica¸c˜ao deve-se separar cada requisito de acordo com a sua caracteriza¸c˜ao, formando dois grandes grupos, o primeiro contendo os requisitos classificados como funcionais e o outro contendo os n˜ao-funcionais. Deve-se tamb´em colocar um identificador para diferenciar futuramente cada requisito, sendo ele funcional ou n˜ao.

No caso do Gerador de Caracteres foram utilizados os c´odigos RF-xxx para identificar os requisitos funcionais (ex. RF-001 - Requisito Funcional 1) e RNF-xxx para identificar os n˜ao-funcionais (ex. RNF-001 - Requisito N˜ao-Funcional 1). Essa ´e a descri¸c˜ao que caracteriza as informa¸c˜oes contidas no terceiro documento da vis˜ao global, veja classifica¸c˜ao abaixo:

Gerador de Caracteres - Separa¸c˜ao e Identifica¸c˜ao

• Funcionais:

– RF-002: “O m´odulo deve ser capaz de converter um c´odigo ASCII para o padr˜ao de visualiza¸c˜ao do “display” de v´ıdeo”;

– RF-003: “O m´odulo deve ser capaz de enviar caracteres para um “display” de v´ıdeo”;

– RF-004: “O m´odulo dever´a controlar os sinais de v´ıdeo necess´arios para o funcionamento do “display””;

• N˜ao-funcionais:

– RNF-001: “Os caracteres dever˜ao ser armazenados em mem´oria”;

– RNF-002: “Os caracteres ser˜ao representados atrav´es do c´odigo ASCII”;

– RNF-003: “Cada endere¸co da mem´oria equivaler´a a um c´odigo ASCII em particular”; – RNF-004: “O “display” de v´ıdeo ter´a a resolu¸c˜ao padr˜ao de uma imagem no

formato CIF(352Cx288L) - Detalhado no padr˜ao H.261 de compress˜ao de v´ıdeo”; – RNF-005: “O mem´oria deve ser capaz de armazenar uma tela completa”; (Requisito

Extra)

– RNF-006: “O “display” dever´a receber dados dos caracteres da linha de forma serial”;

– RNF-007: “O m´odulo deve permitir a visualiza¸c˜ao de caracteres mai´usculos e min´usculos”;

– RNF-008: “O m´odulo deve permitir a visualiza¸c˜ao de espa¸cos”;

– RNF-009: “O m´odulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do “display””;

– RNF-010: “O m´odulo dever´a gerar o sinal de sincronismo horizontal”; – RNF-011: “O m´odulo dever´a gerar o sinal de sincronismo vertical”; – RNF-012: “O m´odulo dever´a gerar o sinal de retra¸co horizontal”; – RNF-013: “O m´odulo dever´a gerar o sinal de retra¸co vertical”;

– RNF-014: “O m´odulo dever´a enviar uma linha de caracteres por vez”;

– RNF-015: “O m´odulo dever´a ser capaz de transformar um c´odigo ASCII em uma matriz de pontos (pixels) 8x8”;

Classificados e devidamente identificados, o projetista deve relacionar os requisitos n˜ao-funcionais e funcionais entre eles. Uma restri¸c˜ao, ou requisito n˜ao-funcional, pode estar diretamente relacionada com uma funcionalidade (requisito funcional). Isso n˜ao ´e regra, algumas restri¸c˜oes podem estar relacionadas a outros fatores, como por exemplo o tempo de projeto.

O quarto e ´ultimo documento da vis˜ao global deve descrever essas rela¸c˜oes de forma clara. Dependendo do projeto, deve-se construir o modelo ou o documento que ser´a utilizado para essa rela¸c˜ao. A metodologia sugere um modelo de fichas, pois ´e bastante funcional e simples. Cada ficha ´e respons´avel pela descri¸c˜ao de uma funcionalidade e suas respectivas restri¸c˜oes. O projetista, no ato de preenchimento das fichas com as rela¸c˜oes, deve identificar o impacto gerado por cada restri¸c˜ao no projeto. As FIGs. 4.2, 4.3, 4.4 e 4.5 comp˜oem o documento final desta etapa.

Gerador de Caracteres - Organiza¸c˜ao final (Vis˜ao Global):

Figura 4.3: Requisito Funcional 002

Figura 4.5: Requisito Funcional 004

4.1.2

Especifica¸c˜ao

A especifica¸c˜ao consiste na an´alise do documento que foi obtido na Vis˜ao Global. Esta etapa tem com o objetivo de identifica¸c˜ao dos atores e dos casos de uso que far˜ao parte do sistema. Como dica, pode-se afirmar que os requisitos funcionais s˜ao grandes candidatos a se tornarem casos de uso e suas restri¸c˜oes podem conter ind´ıcios dos prov´aveis atores. Os conceitos e detalhes a respeito de atores e casos de uso est˜ao descritos na metodologia, se¸c˜ao 3.3.1.

O primeiro documento deste est´agio ´e uma lista com a descri¸c˜ao dos atores e dos casos de uso identificados para o projeto do Gerador de Caracteres.

• Gerador de Caracteres - Atores identificados:

– Mem´oria – Display – Interface

• Gerador de Caracteres - Casos de uso identificados:

– Obter caractere da mem´oria

– Converter c´odigo ASCII em uma matriz de pontos – Gerar seq¨uˆencia de pixels para cada linha

– Gerar sinais de controle

A tarefa de detalhamento dos casos de uso consiste na descri¸c˜ao da seq¨uˆencia de eventos, realizada pelo caso e seus atores, que descreve determinada funcionalidade. Neste documento, um pouco mais elaborado, deve-se relacionar os casos de uso identificados com os respectivos atores, al´em de apontar quais requisitos funcionais foram atendidos. Este segundo documento da especifica¸c˜ao deve estar organizado como demonstra a FIG. 4.6 abaixo.

Gerador de Caracteres - Casos de uso detalhados:

Figura 4.6: Detalhamento dos Casos de Uso

Dentre todos os casos de uso descritos, o projetista deve selecionar aqueles considerados cr´ıticos para o desenvolvimento do projeto. Deve-se analisar a viabilidade da implementa¸c˜ao destes casos, tanto em rela¸c˜ao ao custo quanto `a sua complexidade e o tempo gasto para

implement´a-lo. Quanto maior a experiˆencia do respons´avel em projetos dessa grandeza, maiores as possibilidades de sucesso na escolha dos casos realmente cr´ıticos.

Os dois casos considerados cr´ıticos no projeto do Gerador de Caracteres foram escolhidos devido `a sua complexidade de implementa¸c˜ao. Ainda assim, eles s˜ao considerados vi´aveis para o seu desenvolvimento no projeto.

Gerador de Caracteres - Casos de uso considerados cr´ıticos:

• Gerar seq¨uˆencia de Pixels para cada linha

• Gerar sinais de controle

4.2

Modelagem UML

A pr´oxima etapa no projeto ´e a modelagem UML do Gerador de Caracteres na ferramenta Umbrello. Deve-se fazer uso dos diagramas UML apontados na metodologia (Diagrama de Casos de Uso, de Seq¨uˆencia e de Classes).