Engenharia de Software (SENAC) - 2024

Prévia do material em texto

Aula 01
Segundo Sommerville (2011), os sistemas de software são abstratos e intangíveis. Não são restritos por propriedades materiais nem por leis da Física. Isso permite infinitas possibilidades de desenvolvimento de aplicações sem a intervenção das leis da natureza. Contudo, esse fato pode contribuir para ampliar a complexidade de um software, bem como a dificuldade de entendê-lo ou alterá-lo.
E a Engenharia de Software busca respostas para todas essas questões, pois ela estuda todos os aspectos da produção de software. Desde a concepção de um projeto de software, passando por todo o seu ciclo de vida, até a sua manutenção e, posteriormente, sua desativação ou substituição por outro software mais moderno.
Processo de Software
	A Engenharia de Software utiliza uma abordagem sistêmica que chamamos de processo de software, que compreende uma sequência de atividades que serão encadeadas para compor a produção de um ou mais produtos de software.
Especificação de Software
	A atividade de especificação deve reunir o conjunto de necessidades que o cliente do produto deseja. Essas necessidades são expressas em requisitos funcionais.
Desenvolvimento de Software
	O desenvolvimento pode ser entendido como a fase do projeto em que efetivamente construiremos o software. Escrever programas e preparar o ambiente no qual o software será instalado está entre as tarefas dessa atividade.
Validação de Software
	A atividade de validação deve atestar que o software produzido está em conformidade com a especificação produzida na primeira atividade.
Evolução de Software
	A atividade de evolução pode ocorrer paralelamente a outras atividades. Se o cliente resolver mudar os requisitos, o produto de software será mudado também.
Requisitos de um Software
Requisitos não funcionais ou de qualidade (devem ser determinados na atividade de especificação do software):
· manutenibilidade: desenvolver programas que possam evoluir quando houver novas necessidades dos clientes; 
· confiança e proteção: garantir a segurança da aplicação, de modo que não gere prejuízos físicos ou econômicos;
· eficiência: primar pelo excelente uso dos recursos, como processador e memória de discos para obter a melhor capacidade de resposta que o produto puder alcançar; 
· aceitabilidade: projetar sistemas compatíveis com os usuários finais tornando o software mais compreensível e intuitivo para o uso. 
Aula 02
Conceito de ciclo de vida de software abrange o período de tempo desde a concepção até a descontinuação do uso do software em uma organização, ou seja, as fases de concepção, requisitos, projeto, implementação, testes, implantação, manutenção (ou evolução) e descontinuação do uso (ou retirada de operação).
Já o Modelo de ciclo de vida é definido como um framework de processo e atividades preocupadas com o ciclo de vida, que deve ser organizado em fases, que também atuam como uma referência comum para a comunicação e o entendimento do mesmo (ISO/ IEC 12.207, 2011), ou seja, o modelo de ciclo de vida do software é uma abstração do ciclo de vida real.
Brooks (1987) definiu quatro dificuldades inerentes do desenvolvimento de sistemas de software, que foram: complexidade, conformidade, modificabilidade e invisibilidade.
Foram identificadas três dimensões que as organizações devem focar para a melhoria de seu negócio (nesse caso, construção e evolução de software): pessoas, procedimentos e métodos, ferramentas e equipamentos.
Tipos de Modelos de Processos
1.Cascata: o modelo em cascata foi o primeiro modelo de processo publicado e recebeu este nome devido ao encadeamento entre uma fase e outra.
Pressman (2011) aponta algumas críticas com relação ao modelo em cascata: 
· Fluxo sequencial: dificilmente projetos reais seguem um fluxo sequencial de atividade como o modelo em cascata propõe; 
· Incerteza natural nas fases iniciais do processo: no início de muitos projetos de software existe uma incerteza natural, ou seja, muitas vezes o cliente ainda não consegue estabelecer todas as necessidades explicitamente; 
· Cliente deve ter paciência até a entrega do software: uma versão operacional do software será entregue após a fase de teste de sistema, ou seja, a experimentação do software pelo cliente acontece no momento de colocar em operação. Assim, se houver algum desvio de especificação de requisitos do usuário, isto pode ser desastroso. 
Podemos observar que o modelo em cascata é recomendado quando os requisitos são bem compreendidos e com pouca possibilidade de mudança durante o processo de desenvolvimento do software (SOMMERVILLE, 2011; PRESSMAN, 2011).
2.Incremental: as atividades de especificação, desenvolvimento e validação são realizadas simultaneamente e intercaladas com rápido feedback entre todas as atividades. Assim, o modelo incremental reflete o modo como resolvemos problemas, ou seja, raramente desenvolvemos uma solução completa para um problema e sim um esboço inicial, que será dividido e construído em partes menores.
	As vantagens mais importantes do modelo incremental são (SOMMERVILLE, 2011): 
· Redução no custo de acomodar mudanças de requisitos: quantidade de análise e de documentação é menor do que no modelo em cascata; 
· Validação do cliente a cada entrega de versão: envolvimento do cliente no processo de produção de software a cada validação das versões entregues, através de feedback constante; 
· Entrega mais rápida de uma versão parcial do software para o cliente: entrega de versões parciais do sistema para uso em operação, agregando valor ao processo de negócio do cliente. 
As desvantagens do modelo incremental são (SOMMERVILLE, 2011): 
· Falta de visibilidade no processo: a gerência precisa de entregas regulares para mensurar o progresso, se as entregas são muito rápidas não é viável a produção de documentos que reflitam cada versão do sistema; 
· Degradação da estrutura do sistema com a adição de novos incrementos: mudanças constantes tendem a corromper a estrutura do sistema se não for investido tempo em técnicas de refatoração para a melhoria do software. 
3.Evolucionário: uma característica do software é sua evolução ao longo do tempo, ou seja, conforme as fases do desenvolvimento do software avançam, temos mudanças nas necessidades de negócio e os produtos que mudam frequentemente, como consequência, torna-se inadequado um planejamento linear de um produto de software.
Os modelos de processo evolucionário contemplam esse aspecto de possibilitar o desenvolvimento de um produto que evolua ao longo do tempo e são caracterizados por serem interativos e apresentarem características que possibilitem desenvolvermos versões cada vez mais completas do software.
Conclusão:
	Nesta aula, conhecemos dois modelos de processo de software que têm o mesmo objetivo, ou seja, a produção de um software. O modelo em cascata organiza suas fases de forma sequencial e linear e em cada término de fase temos uma documentação intermediária que documenta o software produzido e fornece suporte às suas manutenções e evoluções futuras. Em contrapartida, apresenta algumas desvantagens, como a acomodação de mudanças de requisitos apenas no final do processo.
	Já o modelo incremental, a cada incremento produz um software que agrega valor ao cliente mais rapidamente e permite acomodar mudanças com mais facilidade, entretanto, a documentação dos artefatos das fases intermediárias não é seu ponto forte, como também não é a visibilidade gerencial das fases.
Aula 03
	Os modelos de processo podem ter seu fluxo de atividades organizado de diferentes maneiras, que são: linear, iterativa, incremental e paralela (PRESSMAN, 2011).
Estratégia Linear: nos modelos de processo que adotam a estratégia linear as atividades são executadas de forma sequencial e encadeada, uma após a outra, começando com especificação de requisitos e finalizando com a manutenção.
Estratégia Iterativa: Já nos modelos de processo que adotam a estratégia iterativa, uma ou mais atividades são repetidas antes de se prosseguir para as seguintes.
EstratégiaEvolucionária: é importante observar que os modelos de processos que adotam a estratégia denominada evolucionária executam as atividades de forma circular e a cada volta conduzem a uma versão mais completa do software.
Prototipagem: Podemos entender um protótipo como uma versão inicial de um sistema de software, usado para demonstrar conceitos, experimentar opções de projeto e ajudar no entendimento do problema e a descobrir possíveis soluções (SOMMERVILLE, 2011).
Modelo Espiral: o modelo espiral é um exemplo de processo evolutivo, ou seja, o software é desenvolvido de forma evolutiva até que o produto final esteja cada vez mais completo, assim, a partir da figura podemos observar que as atividades do modelo espiral evoluem no sentido horário, do centro para fora.
Componentização: Durante as fases do processo de desenvolvimento de software observa-se que alguns artefatos de software gerados (especificações, projeto de arquitetura, código-fonte, casos de teste e outros) são similares, ou até mesmo iguais, a outros confeccionados em outros projetos. O que se percebe que uma grande quantidade de esforço, em geral, é desperdiçada.
	O componente de software é um dos principais artefatos de software que pode ser usado e reusado para a construção de novos sistemas. O reuso de software pode ser obtido por meio do desenvolvimento baseado em componentes, ou seja, um novo sistema pode ser construído utilizando partes (componentes), que foram criadas para compor outro sistema.
	Podemos observar que o reuso de software está implícito dentro dessa abordagem, uma vez que um sistema de software é construído a partir de componentes de software previamente construídos e, além disso, um ou mais componentes podem ter sido utilizados para a construção de outro sistema de software.
Modelo UP (Processo Unificado)
O processo unificado adota o desenvolvimento de software baseado em componentes, ou seja, prevê que o sistema de software pode ser construído através da composição de componentes de software interconectados através de interfaces bem definidas. Segundo Pressman (2011), utilizando a Unified Modeleing Language (UML) – Linguagem de Modelagem Unificada, o processo unificado define os componentes de software que serão usados para construir o sistema e as interfaces, que fornecem meios para a conexão entre os componentes.
Modelo Open UP
. Projetado para suportar equipes pequenas;
. Equipes de 3 a 6 pessoas;
. Duração de 3 a 6 meses.
Aula 04
Movimento Ágil
Em 2001, um grupo de simpatizantes do desenvolvimento ágil se reuniu para escrever o que ficou conhecido como manifesto ágil, que consiste em uma declaração de valores comuns aos processos de software denominados ágeis. O Manifesto Ágil (2001) declara que:
Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e ajudando outros a fazê-lo. Através deste trabalho valorizamos mais: 
· Indivíduos e interações do que processos e ferramentas;
· Software em funcionamento do que documentação abrangente; 
· Colaboração com o cliente do que negociação de contratos; 
· Responder às mudanças do que seguir um plano.
Scrum
O Scrum não é um processo ou uma técnica, é um framework, ou seja, um conjunto de conceitos que são aplicados para resolver um problema de domínio específico. No caso, o problema do processo de software. A ideia básica é compor uma equipe, chamada de equipe Scrum, que terá papéis específicos, eventos e artefatos (documentos, ou qualquer coisa produzida durante o processo) e regras.
Nesse framework, os papéis específicos são: 
.Equipe de Desenvolvimento – É um grupo de pessoas auto-organizável e multifuncional. Você não vai encontrar pessoas com papéis específicos, como desenvolvedor ou tester, todos trabalham multifuncionalmente. Segundo Cohn (2011) o tamanho de equipe ideal é de três a nove integrantes.
.Product Owner – Também denominado de dono do produto, sua responsabilidade é garantir que se dedique ao objetivo correto, para isso, ele redige os requisitos e define as prioridades (COHN, 2011). Ele gerencia o backlog do produto, que é uma lista de tarefas que, quando finalizada, encerra o produto. 
.Scrum Master – É o responsável por garantir que o framework Scrum seja entendido e aplicado pela equipe Scrum e, também, atua como um facilitador para remover impedimentos ao progresso da equipe durante as construções de uma versão do software (COHN, 2011). 
O backlog do produto (ou product backlog) é um artefato Scrum. Representa uma lista ordenada de tudo que deve ser feito no produto. Essa lista é gerenciada pelo product owner. Dessa lista, selecionam-se os itens que serão entregues em um incremento de software. Os incrementos de software são desenvolvidos em sprints. 
Um sprint pode durar de duas a quatro semanas. Isso é dimensionado pela equipe Scrum. Durante um sprint, existem ritos que devem ser seguidos para manter o framework em funcionamento. São exemplos, reuniões diárias, uso do gráfico burndown, burnup ou similares, monitoramento do sprint e outros.
Extreme Programming
Mais conhecido por XP, é talvez o método ágil mais utilizado. O termo XP foi cunhado por Beck em 2000 e se baseou em uma coletânea de práticas reconhecidamente boas, como o desenvolvimento iterativo (por meio de iterações ou fases), ou a programação em pares.
Aula 05
Projeto de Software:
Objetivo: o projeto tem um objetivo definido no início e que deve ser alcançado ao final; 
Ciclo de vida definido: o projeto tem um ciclo de vida que envolve as seguintes etapas: iniciação, planejamento, execução, controle e encerramento; 
Complexidade: um projeto pode existir em diferentes níveis de complexidade, do mais simples ao mais complexo;
Singular: produz um produto, serviço ou resultado único; 
Riscos: a execução de um projeto envolve riscos que podem prejudicar o atingimento de seu objetivo e afetar o resultado; 
Recursos limitados: o projeto envolve recursos limitados de tempo, custo, materiais, equipamentos e pessoas. 
Atribuições e responsabilidades de um gerente de projeto:
Elaboração de propostas: essa é uma das primeiras tarefas de gerenciamento de projetos. A proposta deve descrever objetivo, escopo, restrições e como o projeto deve ser realizado. Pode haver uma previsão de entrega inicial, estimativa de custo e um cronograma. É uma etapa muito importante e a proposta inicial é vital para a aceitação do projeto. Não existe receita de bolo, essa habilidade é adquirida através da prática e experiência em gerência de projetos; 
Planejamento de projetos: o plano de projeto é um esboço de um desejo futuro e os meios para alcançá-lo, para isso, determina um conjunto de métodos e estratégias adotadas para definir: O QUÊ, COMO, QUANDO e DE ONDE. O gerente de projeto é responsável por estabelecer com antecedência as ações a serem executadas, estimar recursos a serem empregados e definir as correspondentes atribuições de responsabilidades para que sejam alcançados os objetivos do projeto. O gerente de projeto também deve controlar e monitorar a execução do plano de projeto, acompanhando o progresso do projeto e tomando ações corretivas caso necessário; 
Gerenciamento de riscos: compreende processos relativos à identificação, análise e respostas para os riscos envolvidos em um projeto. Para isso, tem como objetivo maximizar os resultados dos eventos positivos e minimizar as consequências dos eventos negativos (ou adversos); 
Gerenciamento de pessoas: projetos envolvem pessoas, que devem ser gerenciadas. O gerente de projeto deve ser capaz de formar uma equipe de acordo com as características e necessidades do projeto e, também, estabelecer os mecanismos de trabalho em equipe para obter eficiência da mesma; 
Gerenciamento da comunicação: inclui os processos requeridos para garantir a geração, coleta, disseminação e armazenamento das informações do projeto, de forma apropriada, no momento adequado e para a pessoa certa. 
Cronograma do Projeto
Pode acompanhar o cronograma uma representação gráfica conhecida como Gráfico de Gant, que permitevisualizar a duração das atividades e a sequência de execução em uma linha de tempo.
Podemos observar neste cronograma as fases do ciclo de vida em cascata e as respectivas atividades de cada fase. Cada atividade produz um entregável, assim, fica mais fácil estimar o tempo de duração e, também, associar um recurso para realizar essas atividades. Outro ponto a ser observado é o encadeamento das atividades. Algumas têm dependência do produto gerado por outras atividades e, dessa maneira, é estabelecida uma relação de precedência. Entretanto, outras atividades não têm essas dependências, podendo ser executadas em paralelo.
WBS ou EAP (Estrutura Analítica de Projeto): subdivisão das entregas e do trabalho de um projeto em componentes menores; estruturada em forma hierárquica; fornece uma ilustração detalhada do escopo do projeto.
Aula 06
Tipos de Sistemas
Os sistemas técnicos baseados em computadores são aqueles nos quais temos a integração de hardware e software, porém sem incluir processos ou procedimentos. São exemplos deste tipo de sistema: televisores, carros, tablets, notebooks etc (SOMMERVILLE, 2011). Observe que estes sistemas possuem a parte física – o hardware, e a parte abstrata, o software, responsável por operacionalizar funcionalidades destes sistemas.
Os sistemas sociotécnicos agregam conhecimento e componentes que permitem ir além de atender funcionalidades, ou seja, são capazes de alcançar metas mais elaboradas (SOMMERVILLE, 2011). Esta característica dá condições para estes sistemas apoiarem objetivos organizacionais definidos para uma empresa em específico ou, de modo genérico, para diversas empresas.
Observe também, na figura, que as setas verticais apontam a abrangência da Engenharia de Sistemas, envolvendo as camadas equipamento até organização. Esta é mais abrangente, pois integra pessoas, equipamentos e processos conforme vimos anteriormente. 
No caso da Engenharia de Software, o escopo é mais limitado, preocupando-se mais nos aspectos de produção do software, como já vimos em aulas anteriores.
Propriedades de Sistemas
Propriedades Funcionais: referem-se à finalidade do sistema, por exemplo, um caixa eletrônico de uma Instituição Financeira tem a propriedade funcional de realizar saques, depósitos e transferências entre contas bancárias; 
Propriedades não funcionais: referem-se ao comportamento do sistema em seu ambiente operacional, como, por exemplo, confiabilidade, desempenho, segurança e a proteção, como no caso de um caixa eletrônico de uma instituição financeira, que deve garantir que as transações financeiras de um correntista sejam transmitidas de forma criptografada. 
Conclusão
Podemos observar que aspectos organizacionais e humanos influenciam sobre a aquisição, desenvolvimento e operação destes sistemas sociotécnicos. Neste contexto, a engenharia de sistemas deve preocupar-se em conhecer o ambiente em que esses sistemas estão inseridos, as pessoas e outros sistemas deverão interagir com ele, os processos de negócio que estão inseridos e que automatizam. 
Uma vez que um sistema é desenvolvido por pessoas, erros humanos são inevitáveis. Portanto, os engenheiros de software devem incluir barreiras para detectar esses erros antes que ocasionem falhas no sistema e prejuízos à organização e às pessoas.
Aula 07
Quando iniciamos o desenvolvimento de uma aplicação, as necessidades do cliente são coletadas e, posteriormente, avaliadas e descritas na forma de requisitos. Ao final deste processo, teremos um Documento de Especificação de Requisitos de Software. Este documento representa o escopo do projeto que o cliente deve avaliar e aprovar para a continuidade dos trabalhos.
Tipos de Requisitos
Requisitos de usuário os que são descritos em um nível de abstração mais alto, ou seja, na linguagem natural, mais próxima do usuário. Já os requisitos de sistema são expressos de forma mais detalhada das funcionalidades e restrições a serem implementadas no sistema.
Observe que podemos escrever requisitos de usuários e depois derivá-los para requisitos de sistema, detalhando melhor os aspectos que o envolvem.
Por exemplo, um requisito de usuário “O sistema deve gerar os recibos de pagamentos para os clientes” pode derivar para requisitos de sistema como estes: “O recibo de pagamento deve ser gerado em até 24h do ato do pagamento”, “O recibo de pagamento deve ser encaminhado por e-mail para o cliente”, “O gerente de contas deve ter acesso a uma consulta de recibos pagos”.
Também podemos classificar requisitos como funcionais ou não funcionais. Estes termos são muito comuns e refletem os seguintes conceitos:
Requisitos Funcionais: são aqueles que descrevem funcionalidades do sistema. Referem-se ao resultado de algum comportamento que será fornecido pelo sistema. 
Requisitos não Funcionais ou de Qualidade: descrevem restrições impostas ou características desejadas ao sistema, como desempenho, disponibilidade, confiabilidade, entre outros.
Documento de Especificação de Requisitos de Software
Este documento é anexado a contratos entre desenvolvedores e clientes, pois descreve formalmente o produto que será desenvolvido. Por este motivo, um Documento de Especificação de Requisitos de Software deve conter tanto requisitos de usuário como requisitos de sistema. Também deve conter requisitos funcionais e não funcionais.
Aula 08
Contexto do sistema: é a parte do ambiente que é relevante para a compreensão dos requisitos do sistema a ser desenvolvido. 
Limite do Sistema: é um delimitador entre o que será alterado pelo processo de desenvolvimento e o que não será alterado; 
Escopo
Aspectos que podem ser modificados e projetados durante o processo de desenvolvimento fazem parte do escopo do projeto, que também define quais aspectos pertencem ao ambiente e que não podem ser alterados e que representam, muitas vezes, restrições para o sistema a ser desenvolvido. 
Segundo Pressman (2011), o escopo fornece à equipe de desenvolvimento um destino, ou seja, serve como um roteiro sobre o que deve ou não ser feito. Temos dois tipos de escopo, que são (PMBOK, 2014):
Escopo do produto: define as características e funções que descrevem um produto, serviço ou resultado. 
Escopo do projeto: define o trabalho que deve ser realizado para entregar um produto, serviço ou resultado com relação às características e funções especificadas. 
Documento de visão de projeto
O documento de visão de projeto é um artefato de software desenvolvido na fase de engenharia de requisitos do modelo em cascata e, no caso do processo unificado, é produzido durante a fase de concepção, especificamente durante a de análise de requisitos.
Esse artefato de software estabelece a visão dos envolvidos com relação ao produto de software a ser desenvolvido. Para isso, especifica os termos das principais características e necessidades dos envolvidos, além de contemplar um esboço dos principais requisitos percebidos para o sistema. 
Muitas vezes esse artefato é usado pelas empresas como base para contratação de desenvolvimento de software, uma vez que é possível estabelecer requisitos técnicos, restrições de projeto e de desenho do sistema de mais alto nível e podem especificar alguns aspectos de requisitos comportamentais.
Em comparação com o documento de especificação do sistema, esse artefato está descrito em um nível de abstração mais alto, ou seja, com menos detalhes. Portanto, não substitui o documento de especificação, mas pode nortear a sua elaboração.
Aula 09
Vamos, então, conhecer os diferentes modelos gráficos que podem nos auxiliar na engenharia de software:
UML - Unified Modeling Language
Nos anos 1990, os autores Booch, Rumbaugh e Jacobson (2005) definiram um padrão de notação para um conjunto de diagramas denominado UML - Unified Modeling Language. Esse padrão foi adotado pela OMG - Object Management Group, nos anos 2000, que criou uma especificação largamente utilizada até os dias atuais, pois se tornou um padrão para a modelagem orientada a objetos.
Contudo, a UML não se limita a representarsomente aspectos da orientação a objetos ou outros aspectos estruturais, também fazem parte desse conjunto diagramas que representam aspectos comportamentais de um sistema. 
Booch, Rumbaugh e Jacobson (2005) definiram que os diagramas comportamentais representam a parte dinâmica do sistema e mostram o comportamento ou a troca de mensagens entre os elementos que compõem um sistema. Já os diagramas estruturais representam a parte estática do sistema, mostrando as associações entre os elementos de um sistema.
Modelagem de requisitos 
Pressman (2011) afirma que a modelagem de requisitos pode seguir duas visões distintas: a análise estruturada e a orientada a objetos. 
Análise estruturada: esta visão considera dados e processos transformados em entidades separadas. Os dados são modelados em entidades, atributos e relacionamentos. Os processos são modelados de modo a transformar os dados na medida em que eles trafegam no sistema. 
Orientada a objetos: a visão orientada a objetos está focada na construção de classes de objetos que colaboram entre si para atender às necessidades previstas no projeto. A UML e o processo unificado são baseados nesta abordagem. 
Resumo
A UML vem sendo uma referência para modelagem, seus diagramas são largamente utilizados por profissionais de engenharia de software. 
O diagrama de contexto é construído em um estágio inicial da especificação do sistema e estabelece limites e dependências com outros sistemas dentro do ambiente de sistema em estudo. Cada modelo ou diagrama UML tem a sua contribuição em uma ou mais fases do processo de desenvolvimento, sendo refinado e atualizado a cada ciclo de iteração.
Aula 10
Abstração: Seu objetivo seria isolar os aspectos importantes para uma finalidade e suprimir os aspectos não importantes, determinando, assim, o que é e não é relevante para a modelagem. 
Fundamentos da Orientação a Objetos
Encapsulamento: separação dos aspectos externos de um objeto (que são acessíveis a outros objetos) dos detalhes internos da implementação (que são escondidos em outros objetos). O encapsulamento é o processo de compartimentar os elementos de uma abstração que constitui sua estrutura e comportamento; encapsulamento serve para separar a interface contratual de uma abstração e sua implementação. 
Modularização: consiste em dividir um programa em módulos que podem ser compilados separadamente, mas que tem conexões com os outros módulos. As conexões entre módulos são as suposições que os módulos fazem a respeito dos outros. A modularidade é uma propriedade de um sistema que foi decomposto em um conjunto coeso e fracamente acoplados de módulos. 
Concorrência: é a propriedade que distingue um objeto ativo de um objeto não ativo. A concorrência foca sobre o processo de abstração e sincronização, ou seja, cada objeto (elaborado a partir de uma abstração do mundo real) pode representar um segmento separado de controle (uma abstração de processo). Tais objetos são chamados de ativos. Em um sistema baseado em projeto orientado a objetos, podemos conceituar o mundo como consistindo de um conjunto de objetos em cooperação, alguns dos quais estão ativos e, assim, servem como centros de atividade independente. 
Persistência: propriedade de um objeto em que sua existência transcende tempo (o objeto continua a existir depois de o seu criador deixa de existir) e/ou espaço (localização movimentos do objeto do espaço de endereço no qual foi criado). Ou seja, um objeto em software ocupa certa quantidade de espaço e existe para um determinado propósito por período de tempo. 
Herança: define um relacionamento entre classes na qual uma classe compartilha estrutura ou comportamento definido em uma ou mais classes. Portanto, herança representa uma hierarquia de abstrações, em que uma subclasse herda de uma ou mais superclasses. Ou seja: a subclasse aumenta ou redefine a estrutura e comportamento existentes de suas superclasses. 
Objetos e Classes
A orientação a objetos é a forma de organizar o software como uma coleção de objetos distintos.
Cada uma das bicicletas possui uma identidade, ou seja, os dados são quantizados em entidades distintas e distinguíveis, chamadas de objetos. Dessa forma, cada objeto tem a identidade inerente, ou seja, constituem dois objetos distintos, mesmo que todos os seus valores de atributos (como nome e tamanho) sejam idênticos.
Os objetos que possuem características em comum podem pertencer à mesma classificação, ou seja, aqueles com a mesma estrutura de dados (atributos) e comportamento (operações) são agrupados em uma classe. Podemos concluir que uma classe é uma abstração que descreve propriedades importantes para uma aplicação em um determinado contexto e ignora as demais não relevantes naquele contexto.
A representação de classe do quadro anterior apresenta, além do nome da classe, os seguintes itens: 
Atributo: é uma propriedade nomeada de uma classe, que descreve um valor retido por cada objeto da classe. Podem-se encontrar atributos procurando adjetivos ou abstraindo valores típicos. 
Operação: é uma função ou um procedimento que pode ser aplicado a/ou por objetos em uma classe. Cada operação possui um objeto destino como um argumento implícito. O comportamento da operação depende da classe de seu destino. Um objeto “conhece” sua classe e, portanto, a implementação correta da operação. 
Os objetos interagem entre si através do envio de mensagens. Ou seja, para que uma operação seja executada em um objeto deve haver um estimulo enviado a esse objeto, que pode ser ele mesmo invocando a execução de uma operação dele mesmo ou pode ser de outro objeto invocando a execução da operação.
Para isso, o objeto deve oferecer um conjunto de operação (ou métodos) para os outros que são operações publicas, ou seja, aquelas que os outros objetos podem realizar invocações através de mensagens. Existem outras operações que são as operações chamadas de privadas, ou seja, apenas a própria classe pode invocar.
Herança: generalização X especialização
A herança implica uma hierarquia de generalização/especialização, em que uma subclasse especializa a estrutura mais geral ou o comportamento de suas superclasses. Generalização é o relacionamento entre uma classe (a superclasse) e uma ou mais variações da classe (as subclasses) (BEZERRA, 2007).
A generalização e a especialização são dois pontos de vista do mesmo relacionamento, ou seja, dadas duas classes Funcionário e Vendedor: se Funcionário é uma generalização de Vendedor, então Vendedor é uma especialização de Funcionário.
Assim, para entender a semântica de um relacionamento de herança é preciso lembrar que uma classe representa um conjunto de objetos que compartilham um conjunto comum de propriedades (atributos, operações e associações). Entretanto, alguns objetos, embora bastante semelhantes a outros, podem possuir um conjunto de propriedades que outros não possuem.
Polimorfismo 
O polimorfismo é a capacidade de duas ou mais classes de objetos responderem à mesma mensagem, cada uma do seu próprio modo, ou melhor, com a sua própria forma de implementar o método.
Modelagem CRC
Aula 11
O objetivo desta aula é entender esses dois importantes modelos da UML (Unified Modeling Language - Linguagem de Modelagem Unificada) no processo de desenvolvimento de software, que são: diagrama de classes e diagrama de atividades.
Diagrama de classes 
Segundo Fowler (2005), um diagrama de classes descreve os tipos de objetos presentes no sistema e os vários tipos de associações estáticas existentes entre eles. Além disso, representa os atributos e as operações de uma classe e as restrições que se aplicam à maneira como os objetos estão conectados.
Atributo: é a propriedade nomeada de uma classe, que descreve um valor retido por cada objeto da classe. É possível encontrar atributos procurando adjetivos ou abstraindo valores típicos; 
Operação: é a função ou o procedimento que pode ser aplicado a/ou por objetos em uma classe. Cada operação possui um objeto-destino como um argumentoimplícito. O comportamento da operação depende da classe de seu destino. Um objeto “conhece” sua classe e, portanto, a implementação correta da operação. 
Associação 
Uma associação é uma representação para o relacionamento que pode existir entre duas (ou mais) classes no diagrama de classes. A existência de um relacionamento entre objetos que possibilita troca de mensagens entre eles, ou seja, consiste em relacionamentos entre os objetos que permitem a colaboração entre eles a fim de produzir as funcionalidades do sistema (BEZERRA, 2007). É importante ressaltar que, quando se refere a relacionamento no contexto de objetos, este processo é chamado de ligação.
Multiplicidade 
A multiplicidade, por exemplo, representa quantos objetos estão envolvidos em uma associação entre classes. Na associação entre a classe Cliente e Pedido existe uma multiplicidade de 1 para muitos (1..*), isto significa que um objeto Cliente pode ter várias ocorrências de Pedidos associados a ele, como também pode não ter nenhum, e um Pedido está associado a uma única ocorrência de um objeto Cliente.
Conclusão
Tal como um modelo UML classificado como estrutural, o diagrama de classes permite a organização e arquitetura de um sistema de software, para isso ele define a estrutura estática das classes do sistema e suas associações entre elas. 
Já o diagrama de atividades favorece a modelagem do comportamento dinâmico do sistema, permitindo modelar o processamento de dados, sendo que cada atividade representa uma etapa deste processamento de dados.
Aula 12
Tradução de Diagrama para Código
A partir de um diagrama detalhado, podemos ter uma tradução direta para um código-fonte de programação. Chamamos esta operação de engenharia forward ou, como foi traduzida em alguns livros, engenharia de produção. O inverso desta operação, traduzir um programa para um diagrama, chamamos de engenharia reversa. 
Estas operações podem ser realizadas com sucesso em ferramentas apropriadas para isso, como as CASE (Computer-Aided Software Engineering, ou Engenharia de Software auxiliada por computador). Essas ferramentas que permitem não só desenhar diagramas, mas verificam as suas regras de construção. De modo complementar, elas permitem conexão com o ambiente de desenvolvimento de programas e traduzem os códigos para diagramas, utilizando a nomenclatura utilizada nos códigos e vice-versa, ou seja, a partir dos nomes, blocos e comunicações estabelecidas no diagrama, a ferramenta traduz o conjunto para códigos-fonte de programação.
Aula 13
Exemplo de padrão arquitetural: MVC 
O padrão MVC (Model-View-Controller ou em português Modelo-Visão-Controlador) é um padrão arquitetural muito adotado em sistemas baseados em WEB para o gerenciamento da interação (SOMMERVILLE, 2011). 
Os componentes do MVC são basicamente: 
Modelo (model): é o objeto de dados da aplicação, ou seja, que pertence ao domínio do problema; 
Visão (view): é o objeto de apresentação da tela, ou seja, estabelece como os dados serão apresentados para o usuário; 
Controlador (controller): é o objeto que estabelece como o sistema reage aos estímulos gerados pelo usuário através do objeto de apresentação (view) e passa as interações dos objetos View para os Objetos Model. 
Exemplo de padrão de projeto: observer
Basicamente, o padrão Observer é aplicado em situações nas quais diferentes apresentações de estado de um objeto são requeridas e, assim, mudanças no estado do objeto devem refletir nestas apresentações. Como, por exemplo, em sistema Web que adota MVC as mudanças nos dados de um objeto Model (Modelo) devem ser refletidas nos objetos Views (Vistas) que apresentam estes dados para o usuário (e vice-versa).
Aula 14
Segundo Pressman (2011, p. 401), o teste de software é um elemento de um contexto mais amplo, muitas vezes referido como verificação e validação (também chamado de V&V). Estes dois conceitos (verificação e validação) são diferentes entre si, entretanto, complementares. Pressman (2011) define que: 
Verificação: é o conjunto de atividades que garante que o software implemente corretamente uma função específica. 
Validação: é o conjunto de atividades que garante que o software construído corresponda aos requisitos do cliente (ou usuário). 
Já para Sommerville (2011), os processos V&V têm o objetivo de verificar se o software em desenvolvimento satisfaz suas especificações e se possui as funcionalidades esperadas pelos clientes e usuários. Entretanto, o processo de verificação tem o objetivo de checar se o software atende aos requisitos funcionais e não funcionais; já o processo de validação tem o objetivo de garantir que o software atenda às expectativas dos clientes e usuários, ou seja, tenta demonstrar que o software executa o que o cliente espera.
Tipos de teste de software 
Em uma estratégia de teste de software podem existir dois tipos de teste, que são (SOMMERVILLE, 2011): 
Testes estáticos de V&V: nesta técnica não é necessária a execução do programa, software ou código-fonte; 
Testes dinâmicos de V&V: nesta técnica é necessária a execução do programa, software ou código-fonte. 
Os testes de inspeção de software são um exemplo de testes estáticos. Segundo Sommerville (2011), as inspeções de software têm o foco no código-fonte, mas podem ser aplicadas a qualquer outro artefato do processo de desenvolvimento, tais como: documentos de especificação de requisitos, modelos de projeto ou de arquitetura. 
Os testes dinâmicos exigem a execução do programa e podem ser realizados manualmente ou de forma automatizada. No caso de teste manual, um testador (ou tester) executa o programa com alguns dados e compara os resultados com a expectativa relacionada ao esperado e reporta os resultados; já nos casos de testes automatizados, os testes são codificados em um software que os executa cada vez que o software em desenvolvimento é testado (SOMMERVILLE, 2011).
O teste unitário concentra o esforço na menor unidade de projeto de software que pode ser uma classe (no caso de orientação a objetos) ou um módulo de sistema. Para isso, procura validar a especificação da classe ou módulo com relação à sua implementação com enfoque na lógica interna de processamento e nas estruturas de dados considerando os limites da classe ou módulo. 
Já o teste de integração (ou de componente) é uma técnica para compor os módulos (ou classes) na arquitetura do software enquanto desenvolve teste para identificar erros associados às interfaces entre os módulos (PRESSMAN, 2011). O teste de integração pode aplicar a técnica de integração descendente (top-down) ou a de integração crescente (botton-up). 
O teste de validação é realizado após o teste de integração. Neste tipo de teste o foco são as ações visíveis ao usuário e as saídas do sistema reconhecidas por ele. Para isso, pode ser estabelecido um critério de teste de validação ou aceitação. O critério de teste de validação ou aceitação consiste em uma série de testes que demonstram que o software está em conformidade com os requisitos do usuário (PRESSMAN, 2011, p. 418). 
Fazem parte do teste de validação os testes alpha e beta que são realizados pelo usuário final. Basicamente, o teste alpha é realizado pelo usuário final, mas é conduzido no ambiente do desenvolvedor, ou seja, sob a tutela dele. Já o teste beta é também realizado pelo usuário final, mas em seu ambiente e na presença do desenvolvedor. 
O teste de sistema deve verificar se os componentes do sistema são compatíveis, se interagem corretamente através de suas interfaces e transferem dados certos no momento certo e, além disso, se está em conformidade aos requisitos funcionais e não funcionais. Para isso, o teste de sistema engloba uma série de diferentes tipos de teste que têm a finalidade de promover um exercício completo do sistema.
Técnicas de teste de software
Basicamente, temos dois tipos de técnicas de teste de software: caixa-branca e caixa preta.
Testes caixa-branca 
Nesta técnica, os casos de teste são projetados conhecendo a estrutura interna do módulo ou componente, ouseja, os testes são projetados para exercitar a lógica interna do módulo.
Testes caixa-preta 
Esta técnica abrange os casos de teste projetados a partir da especificação do módulo ou componente, sem considerar sua estrutura interna. 
O teste caixa-preta, também conhecido como teste comportamental, tem o foco nos requisitos funcionais do software, ou seja, os casos de teste são derivados de conjuntos de condições de entrada que permitiram exercitar os requisitos funcionais do software (PRESSMAN, 2011, p. 438).
Diferença entre teste de software e depuração de software
Segundo Pressman (2011) o teste de software é uma ação planejada, especificada e executada e, a partir de seus resultados, um relatório é gerado com foco nas expectativas prescritas. Neste contexto, o processo de depuração ocorre a partir de um teste bem-sucedido, ou seja, um teste que identificou um erro. 
Assim, a depuração inicia as suas atividades a partir de um erro reportado que deve ser identificado e localizado e, posteriormente, removido. Podemos afirmar que o processo de depuração sempre ocorre em decorrência de um teste bem-sucedido, ou seja, um teste que reportou um erro.
Aula 15
Reengenharia de software 
Outro aspecto relacionado ao processo de mudanças diz respeito aos sistemas legados. Consideramos legados os sistemas mais antigos, desenvolvidos em tecnologias anteriores às atuais. Nesses casos, um processo de evolução pode ser complexo, pois envolve a compreensão de artefatos muitas vezes não documentados ou que não foram desenvolvidos com boas práticas. Nessas situações, uma opção é fazer uma reengenharia de software.
Aula 16
Já a garantia da qualidade (ou, do inglês, QA - Quality Assurance) é a definição de processos e padrões que devem conduzir a produtos de alta qualidade e à introdução de processos de qualidade na fabricação (SOMMERVILLE, 2011). Muitas vezes a garantia de qualidade significa a definição de procedimentos, processos e padrões que visam manter ou reforçar a qualidade já existente no contexto de uma equipe de desenvolvimento de software.
Entenda que um processo de qualidade é instalado de modo independente do processo de desenvolvimento de software, a fim de verificar entregáveis, para que estas sejam consistentes e estejam em conformidade com os padrões exigidos pelo cliente. Prega-se, portanto, que a equipe de qualidade seja independente da equipe de software para alcançar maior efetividade nessas atribuições.
Existem vários itens que podem ser medidos e comparados entre projetos, vamos a alguns exemplos relacionados ao código: 
Fan-in: número de funções ou métodos que chamam outra função ou método; 
Fan-out: número de funções que são chamadas por uma função ou método; 
Comprimento de código: tamanho do código ou número de linhas de código; 
Profundidade de alinhamento condicional: IF dentro de IF, quanto mais, maior a probabilidade de erro. 
Webs:
Modelos de Processos de Desenvolvimento Software
Modelo Cascata ou Linear:
· Pouco diálogo com o cliente
· Projetos de curta duração e mais pontuais
· Segue um modelo mais engessado, seguindo cada etapa em ordem
Modelo Incremental ou Evolucionário:
· Surge através de um esboço
· Atividades simultâneas 
· Diversas versões desenvolvidas até chegar na versão final
· Entregas do projeto em diversas partes