Resumo da aula 13 – v1.0

————————————————————————————————————–

Siglas importantes:

————————————————————————————————————–

SGBD = Sistema de Gerência de Banco de Dados = faz o controle de acesso ao banco de dados.

CRM = Customer Relationship Management = software que ajuda a personalizar o atendimento aos clientes.

ERP = Enterprise Resource Planning = ajuda em alguns assuntos da empresa, como contabilidade, estoques, entre outras áreas da empresa.

DataWarehousing – processo de extração, transformação e armazenamento de informações de bancos de dados operacionais em bancos de dados especializados multi-dimensionais.

————————————————————————————————————–

Desenvolvimento de Software:

————————————————————————————————————–

Podemos dizer que o desenvolvimento de software é dividido em 3 partes:

- Definição (entender o que o cliente deseja)

- Arquitetura

- Implantação

Em todas as etapas deve-se ter a preocupação de manter a qualidade do software, sempre seguindo o lema “Quality is job one!”.

O lucro obtido com a produção de softwares deve-se principalmente ao fato de que produzir a cópia, um segundo software, é muito barato. O custo de produção do primeiro software é alto, pois necessita-se de profissionais qualificados e diversos outros investimentos. Além disso, empresas como a Microsoft não garantem a corretude do software, portanto, não existe a preocupação de serem processados por mau funcionamento de algum produto. A empresa garante apenas a troca do produto por um outro igual caso ocorra algum problema.

————————————————————————————————————–

Conferência de Engenharia de Requisitos:

————————————————————————————————————–

* PMI = Project Management Institute = Gerência de requisitos para obter uma maior qualidade do produto final.

* Rastreabilidade = Ajuda a reduzir os custos com manutenção e garante maior qualidade do software produzido, pois aumenta a cobertura de testes.

* As pessoas que trabalham na produção e gerência de requisitos deveriam trabalhar em conjunto com o pessoal da área de testes, o que ajudaria a aumentar a qualidade e a eficácia do sistema gerado.

Resumo das aulas de PES: Aula 12 v1.0

Nessa aula, fomos apresentados ao Diagrama de Fluxo de Dados (DFD).

Segundo Edward Yourdon, conceituado pioneiro na metodologia de Engenharia de Software, um DFD é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por “duto” e “tanques de armazenamento de dados”.

Um DFD é muito utilizado como ferramenta de modelagem de sistemas operativos aonde as funções do sistema sejam de fundamental importância.

DFD Nível 0 (Diagrama de Contexto)

Neste nível o Diagrama de Fluxo de Dados pode ser chamado de Diagrama de Contexto, por ser uma forma mais genérica do DFD, de onde derivará os outros níveis. No nível 0, o DFD consiste de apenas uma única bolha, representando o sistema inteiro, com os fluxos de dados mostrando as interfaces entre o sistema e os terminadores externos.

Os componentes de um DFD são:

• Sub-sistema – também conhecido como processo, bolha, função e transformação. É representado por um círculo.
• Relação – Também conhecido como fluxo, é graficamente representado por uma seta que entra ou sai de um processo. Serve para mostrar o movimento de fragmentos ou pacotes de informação. Representa dados em movimento, enquanto os depósitos são dados em repouso.
• Entidades externas – conhecido também como terminador, é representado por um retângulo. Representa um objeto, ou conjunto de objetos que esteja fora do controle do sistema modelado. Pode ser até mesmo outro sistema com o qual nosso sistema irá se comunicar.

 

 

DFD Nível 1 e outros inferiores

Como falado em sala pelo professor, uma analogia que poderíamos usar para criar os outros níveis, seria de pegarmos um sub-sistema e deixarmos cair no chão, se fragmentando em diversas outras partes, que dariam origem ao segundo nível do DFD.

De acordo com Yourdon, o número de níveis pode variar. Cada sistema será um caso atípico e deverá ser analisado como tal. Uma sugestão é de que cada figura de DFD não tenha mais do que meia dúzia de bolhas e depósitos a elas relacionados. Toda vez que isso for “furado”, deve-se criar um novo nível abaixo desse.

Para se garantir a consistência dos níveis entre si, os fluxos de dados que entram e saem de uma bolha em um nível devem corresponder aos fluxos que entram e saem de uma figura inteira do nível imediatamente inferior que descreve aquela bolha. Seguindo o princípio aprendido em sala para modelos de Decomposição Funcional: “Tudo que entra, entra! Tudo que sai, sai!”.

Como componentes do DFD nível 1 e os outros níveis inferiores, temos:

• Sub-sistemas – assim como no Diagrama de Contexto, é representado por um círculo.
• Relação – idem ao nível 0.
• Buffer – responsável por servir como depósito de dados em repouso, contrapondo com a relação, onde esses dados estão em movimento.

 

Resumo das aulas de PES: Aulas 10 e 11 v1.0

Diagrama de casos de uso

Esse diagrama serve para descrever uma funcionalidade do sistema. Muitas vezes é o primeiro diagrama a ser feito na especificação do sistema. Ele é um diagrama comportamental, ou seja descreve o comportamento esperado da funcionalidade.
O diagrama é composto por atores , que podem ser humanos ou um sistema. Eles serão so sujeitos dos comportamentos esperados.
Na descrição de um caso de uso eles dos atores temos as pre e pos condiçoes e Sequencias de comportamentos esperados.

Exemplo retirado do site wikipedia - http://pt.wikipedia.org/wiki/Caso_de_Uso

Número	Nome do caso de uso
2	Consultar áreas de formação de empresas para estágios
Descrição
Obtenção de uma lista, ordenada por área de formação, das empresas quefornecem estágios à instituição interna
Actores
Funcionário da instituição interna
Pré-Condições
Autenticação do funcionário junto do sistema
Sequência normal de acções
Selecção de opção de consulta de área de formação Especificação dos critérios a pesquisa Critério default será a apresentação de todas as empresas por todas as áreas de formação Confirmação de pesquisa
Pós-Condições
Apresentação de uma lista de áreas de formação correspondente aos critérios definidos Possibilidade de exportar para formatos pdf ou excel

 

Diagrama de Classes

Nos fornece uma visão geral do sistema, mostrando suas classes e suas relações, embora de maneira estática porque não consegue mostrar o que acontece, apenas o que interage. O diagrama de classe é composto por caixas que representam as  classes e setas que indicão as relações. Dentro da caixa das classes tem o nome da classe, os atributos da classe e os metodos da classe. As relações entre as classes podem ter diversas cardinalidades como 1 para 1 ou mais, 1 para 0 ou mais, 1 para 1, etc.
No exemplo de um esquema de elevador, usado em sala, tivemos um diagrama feito pelo professor (Fig. 1).
No diagrama de classes, existem 3 tipos de relação: associação, agregação e generalização.
A navegabilidade, que informa qual o sentido da associação. Se nada for informado, então o sentido é bi-direcional. No diagrama da figura 1, o triângulo com a inscrição Chega abaixo, indica que o sentido da associação é de “Elevador chega ao Andar”.
A multiplicidade de uma associação indica o número de possíveis instâncias de uma determinada classe quando relacionada com outra.

 

[figura 1]

 

Diagrama de Seqüência

Enquanto no Diagrama de Classes temos um modelo estático, no Diagrama de Seqüência encontramos o contrário: um modelo dinâmico que mostra como as mensagens são trocadas e quando assim são.

A progressão do tempo se dá conforme a página vá descendo e os objetos são listados da esquerda para a direita.

Nesse modelo, nós temos linhas de tempo de vida, representando o tempo de existência de um objeto e setas para representar as mensagens trocadas entre os objetos. Essas setas atingem barras de ativação, que representam o tempo de duração da mensagem.

Diagrama de Colaboração

Neste tipo de diagrama, também dinâmico, temos um esquema parecido com o Diagrama de Seqüência. Ao invés de nos preocuparmos com o tempo das mensagens enviadas, o foco fica nas funções realizadas pelos objetos.

As funções são os vértices e as mensagens são os links de conexões. Nos retângulos dos objetos ficam escritos as classes, ou nome dos objetos, ou até mesmo ambos. Nos links de conexões das mensagens ficam numerações seqüenciais dando a idéia de navegabilidade entre os objetos.

[figura 2]

Diagrama de Estado

Como os objetos possuem atitudes e estados, o estado de um objeto fica atrelado a sua atividade corrente ou condição. Um Diagrama de Estado mostra as diversas possibilidades de estado de um objeto e a transição responsável por fazer tal objeto mudar seu estado.

Cada estado relaciona-se com um conjunto de transições que determinam o próximo estado de dado objeto. Os estados são retângulos arredondados. As transições são as setas de um estado para outro.

O estado inicial fica representado por um círculo fechado, enquanto o estado final fica por círculo fechado dentro de outro círculo aberto, conforme diagrama de exemplo abaixo.

[figura 3]

 

Resumo das aulas de PES: Aulas 8 e 9 v1.0

Cenários:

 

Definição: “Um cenário é um conjunto ordenado de interação entre parceiros, normalmente entre um sistema e um conjunto de atores externos ao sistema. Pode consistir numa sequência concreta de passos de interação (instância de cenário) ou num possível conjunto de passos de interação (cenário tipo). (Jacobson, 1992)” (texto retirado do site Wikipedia)

 

Modelo de utilização de Cenários:

Título: Título da situação Objetivo: Objetivo Contexto: Pré-Condição Localização geográfica Localização temporal Recursos: Recursos utilizados na situação Atores: Aqueles que interferem na situação (pessoas, sistemas, etc…) Episódios: Ações (necessário que tenha mais de uma ação)

Exemplo:

Situação: Entrega de uma correspondência

Título: Entrega de correspondência Objetivo: Fazer com que a correspondência chegue ao seu destinatário Contexto: Correspondência postada, endereço do destinatário, horário comercial Recursos: Transporte, osso, caixa de correio, taxa Atores: Carteiro, cachorro, alfândega, destinatário, transportadora Episódios: A correspondência passa pela alfândega à Restrição: Pagamento tem validade de 20 dias Destinatário paga a taxa Transportadora leva pacote para o endereço do destinatário Entregador dá osso para o cachorro comer à Restrição: deve ser feito em até dois minutos Entregador coloca pacote na caixa de correio Exceção: taxa não foi paga

 

Para verificar se a construção do cenário está correta devemos observar os itens listados abaixo:

 

1. Veja se todos os itens da linguagem foram utilizados.
2. Confirme se todos os recursos foram mencionados ou devidamente referenciados; faça o mesmo com atores.
3. Veja se o conjunto de episódios é coerente com o objetivo.

 

Mais sobre o assunto pode ser encontrado no site pt.wikipedia.org/wiki/Cenários

Princípio da decomposição:

 

Um sistemas pode ser dividido em sub-sistemas. Em sala de aula foi apresentado um modelo de cenário descrito através do modelo entidade-relacionamento e neste caso tínhamos um cenário decomposto em subcenários menores (um episódio descrito como cenário, por exemplo, nos dava uma idéia clara de que cenários podem ter subcenários). A relação entre os cenários pode ser também por exceção e por pré-condição.

 

Estratégias de verificação:

 

- Ciclo Autor/Leitor

 

Nesta estratégia de verificação todo documento gerado (autor) deve ser lido por alguma pessoa (leitor), de modo a ser feita uma revisão nesse documento, pois é na fase de leitura que serão encontradas falhas ou pontos a serem melhorados. Com isso aumenta-se a qualidade do documento gerado.

 

- Inspeção (Fagan)

 

Nesta estratégio de verificação forma-se uma equipe composta por: moderador, secretário, autores e revisores. As atividades envolvidas no processo de produção de um documento são divididas em: preparação (produção do documento), leitura (geração de uma lista de itens com problemas encontrados), reunião (discussão dos problemas encontrados e o que deve ser feito), revisão (conserto das falhas encontradas). Desta forma, no final é obtido um documento revisado pelo autor levando em conta as falhas encontradas pelo(s) leitor(es), ou seja, um documento mais confiável, de melhor qualidade.

 

Teoria Geral de Sistemas:

 

- Relacionamento “parte-de”

 

A decomposição é um relacionamento do tipo “parte-de” entre a parte e o todo. Como exemplo podemos citar o relacionamento das partes de uma cadeira, onde o todo (cadeira) possui diversas partes (estofado, pés da cadeira, etc) e essas diversas partes formam a cadeira.

 

- Relacionamento “é-um”

 

Segue o princípio de orientação à objetos e especialização. O objeto mais geral apresenta características comuns à todos os objetos mais específicos relacionados a ele através de um relacionamento “é-um”. O objeto mais geral seria a classe que possui as características semelhantes à todos os demais objetos que herdariam essa classe (mais específicos) . Como exemplo, relacionamento de cadeira e mesa para móvel, onde móvel é a classe mais geral e os objetos mesa e cadeira herdam a classe móvel, pois são móveis e possuem outras características específicas.

Resumo das aulas de PES: Aulas 4 a 7 v1.0

Resumo das aulas de PES: Aulas 4 a 7 v1.0

Na aula 4 falamos sobre as regras 4, 5 e 6 de disciplina. Essas regras já foram listadas e explicadas no resumo anterior.

Modelos:

Os modelos servem para organizar as informações. As vantagens dos modelos são: simplificam (combatem a complexidade), organizam, estabelecem uma linguagem comum e facilitam a sistematização. É necessário saber que para modelar é necessário utilizar uma linguagem artificial ou um conjunto de linguagens.

1.Fluxograma

Bohm e Jacopini demonstraram que qualquer programa computável pode ser escrito utilizando-se apenas três estruturas de controle: seqüência, seleção e repetição.

Os programas podem ser representados por fluxogramas e o uso desses no projeto de programas de computadores contribui bastante para a obtenção de programas bem-estruturados e confiáveis. Mais sobre esse assunto pode ser encontrado em www.cefetba.br/fisica/NFL/Java/linguagemestruturada.html.

Elementos para representação em fluxogramas:

2. Modelo Entidade-Relacionamento

O Modelo de Entidades e Relacionamentos é um modeo que serve para descrever os dados (que ficam em entidades) e como esses dados estão relacionados (que são os relacionamentos).

Elementos para representação no modelo entidade-relacionamento:

3.Modelo Caso de Uso

Segundo Ivan Jacobson , podemos dizer que um caso de uso é um “documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo”. Os casos de uso têm uma perspectiva de ator. Mais sobre o assunto em www.macoratti.net/net_uml2.htm.

4. Diagrama de Classes

Um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos. Define todas as classes que o sistema deve possuir.

UML é um conjunto de linguagens, dentre as quais se encontra o diagrama de classes.

Regras de bom desenho:

1. Information Hiding

É a regra de encapsulamento. “Se A não revela seus segredos para B, então B não pode estragar A.”

2. Coesão Alta

A clusterização, o agrupamento em blocos é uma maneira de se ter uma coesão alta. A melhor coesão é a funcional e a pior é a randômica, pois unir funções e partes do sistema levando em conta a sua funcionalidade ajuda na compreensão do sistema como um todo, enquanto unir de forma aleatória coisas que não têm nada a ver não ajuda nesse aspecto.

3. Acoplamento Baixo

O acoplamento baixo seria uma ligação fraca entre os blocos do sistema. Isto é bom pois fica mais fácil gerenciar os efeitos do código de um módulo sobre os outros módulos do sistema.

Modelos são muito importantes!

Modelos são espelhos da realidade e por isso eles se tornam úteis, pois pode-se tratar o modelo e não o real. Modelos sem ambiguidade são bons modelos e para que os modelos não sejam ambíguos é necessário que sejam feitos a partir de uma linguagem não ambígua.

Tabelas de decisão:

Nessa técnica são enumeradas todas as combinações existentes levando em conta as condições explicitadas e as ações a serem tomadas em cada condição.

Árvores de decisão:

Tanto as tabelas de decisão quanto as árvores de decisão são técnicas que visam antecipar os problemas que possam vir a ocorrer e desta maneira saber que atitude tomar caso isso aconteça.

Baseline

“A baseline de requisitos é entendida como o conjunto de requisitos que compõe o documento de requisitos de software (Software Requirements Specification – SRS). Estes requisitos são gerados após as várias fases do processo de requisitos (elicitação, modelagem, análise) e compõem a base para a construção do software. Alterações em requisitos inseridos numa baseline requerem justificativas e aprovação.” (http://www-di.inf.puc-rio.br/~julio/rastreabilidade5.pdf )

Escopo

O escopo do software é definido a partir de um universo de informações e só depois de definido o escopo é que são criados os modelos.

Codificando

A escrita de código por parte do programador envolve uma grande gama de opções que podem ser utilizadas para realizar a mesma coisa, como é o exemplo de um aninhamento de if ou um case. Além disso, para escrever código devemos prestar atenção tanto na linguagem natural quanto na linguagem artificial saber usar as duas para tornar o código mais légivel.

Para um software ser eficaz é necessário que ele atenda os requisitos.

Elicitar requisitos é escrever documentos que irão ajudar no desenvolvimento do sistema a ser criado.

Existem várias maneiras de elicitar os requisitos:

• Conversando com o cliente
• Conhecendo a plataforma
• Fazendo entrevistas, reuniões, questionários
• Através da leitura de documentos
• Etnografia
• Observação
• Engenharia reversa
• Reutilização
• Participação ativa de clientes (interessados)

Não basta elicitar e modelar os requisitos, mas deve-se fazer também uma análise para garantir a qualidade. Para isso pode-se usar técnicas de Verificação e Validação, onde a verificação é uma tarefa que não depende do cliente enquanto a validação depende.

Resumo das aulas de PES: Aulas 1 a 3 v1.0

A construção de softwares em níveis de qualidade desejado e na faixa de custo escolhida é facilitada pela utilização de MTFs (métodos, técnicas e ferramentas) disponibilizadas pela engenharia de software.

 

Apesar da dificuldade em escolher, dentre a grande quantidade de métodos, técnicas e ferramentas, aquelas que se enquadram melhor ao seu problema, a falta de utilização dessas MTFs acarretam em graves problemas na produção e/ou uso do software.

 

A engenharia de software fornece subsídios aos profissionais, através de métodos, que ajudam na própria seleção desses conjuntos de MTFs. No entanto, para a construção de softwares de boa qualidade não basta apenas o conhecimento em engenharia de software, mas também é necessário o conhecimento do domínio em que o software será aplicado e da máquina computacional da qual o software fará parte. Para isso, é inevitável que os engenheiros de software tratem o problema da descrição informal para a descrição formal e também modelem adequadamente as restrições da máquina escolhida.

 

Eficácia X Eficiência

 

Eficácia: determina o quanto uma organização realiza os seus objetivos. Tem a ver, como por exemplo, com o software atender à necessidade que foi proposta.

 

Eficiência: determina o quanto uma organização usa corretamente seus recursos. É realizar atividades ou tarefas de maneira certa e inteligente, com o mínimo de esforço e com máximo aproveitamento de recursos. Tem a ver com o custo.

 

Para garantir a corretude dos softwares produzidos e, conseqüentemente sua qualidade, não basta realizar testes, pois esses mostram a presença de bugs, mas não garantem a sua ausência. Desta forma, outras técnicas devem ser utilizadas para garantir a corretude como, por exemplo, a técnica de análise que se divide em verificação e validação ( V&V ).

 

Inspeção: método eficaz de garantia de qualidade baseado na verificação com custo baixo.

 

Artista X Artesão

 

O trabalho do artista envolve criatividade, enquanto um artesão é uma pessoa que aprendeu alguma técnica e simplesmente a reproduz para obtenção de um produto final. O trabalho de um artesão não tem a ver com criatividade e sim com reprodução de algo já feito alteriormente. No caso do engenheiro de software devemos nos perguntar: Até que ponto vai a criatividade do engenheiro de software? Até que ponto seu trabalho é seguir normas?

 

É claro que a criatividade é importante, mas é fundamental que o engenheiro de software tenha disciplina principalmente devido a complexidade que podem atingir os softwares produzidos.

Regras da disciplina:

Regra 1: Todo documento deve ter: título, autoria, data, versão e indicador de conteúdo (tamanho).

Neste caso entende-se por documento o software produzido, os cenários, léxicos, dentre outros.

Regra 2: P {S} Q

Sempre que descrever algo em documentos, deve-se atentar para o uso de pré e pós-condições. É a maneira disciplinada para garantir que o que escreveu segue aquilo que tinha em mente antes de escrever.

Regra 3: [3,6]

Quando decompomos/dividimos algo devemos fazê-lo de tal modo que a divisão resulte em no mínimo 3 partes e no máximo 6 partes.

Regra 4: Evite inventar nomes.

Deve-se utilizar nomes que tenham sua semântica compartilhada e que sejam o mais simples possíveis, isto é com um número de denotações baixo ( o ideal seria uma única denotação).

Regra 5: “Small is beautiful”– “Clean Design” — “Simple Solutions”.

Procurar trabalhar com conteúdos pequenos, procurar fazer desenhos que sejam o mais limpos possíveis e procurar soluções simples, mas não simplistas.

Regra 6: Mantenha um livro diário.

Um livro diário é um caderno onde são feitas as anotações sobre o seu trabalho.

 

Aliás, o nome do autor de “The Mythical Man-Month” é Frederick Phillips Brooks, Jr.