RESUMO

RESUMO

Nos primeiros slides será feito um breve resumo para relembrar o conteúdo já estudado

Engenharia de Software

8 Princípios de um

 PÚBLICO: Os engenheiros de sw devem agir consistentemente com o interesse público  CLIENTE E EMPREGADOR: os engenheiros

do sw dever agir dentro dos melhores interesses de seu cliente e empregador.  PRODUTO: devem assegurar que seus

produtos e as modificações a eles relacionadas atendam aos mais altos padrões profissionais possíveis

 JULGAMENTO: devem manter a integridade e a independência em seu julgamento

 GERENCIAMENTO: os gerentes e líderes de

engenharia devem aceitar e promover uma abordagem ética no gerenciamento de desenvolvimento e manutenção de sw.

 PROFISSÃO: devem promover integridade e

a reputação da profissão de forma consistente com o interesse público.

 COLEGAS: devem ser honestos e

colaborativos com seus colegas.

 INDIVÍDUOS: devem participar, ao longo da

vida, aprendendo, respeitando e promovendo uma abordagem ética na prática da profissão.

Métodos Ágeis

 Os Métodos Ágeis são algumas vezes chamados

de métodos leves ou magros. Que tem por objetivo minimizar o risco pelo desenvolvimento do software em curtos períodos de tempo, chamado de

iteração. Enfatizando a comunicação em tempo real, principalmente face a face, do que a

documentos escritos.

 Alguns métodos ágeis são suplementos com guias

para direcionar o gerenciamento do projeto, centre eles tem o PRINCE2™, Scrum, Programação

Requisitos

de

Requisitos de Software

 São descrições de um sistema dos serviços fornecidos pelo sistema e as suas restrições operacionais.

 Esses requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver

algum problema.

 Podem ser definidos assim: Documento de

requisitos de software, requisitos não funcionais e funcionais, requisitos de usuário, requisitos de

 Os requisitos de um sistema de software definem o que o sistema deve fazer e as restrições sobre suas operações e a sua implementação.

 Os requisitos funcionais são declarações dos serviços que o sistema deve fornecer ou são descrições de como algumas computações devem ser realizadas.

 Os não funcionais restringe o sistema que está sendo desenvolvido e o processo de

desenvolvimento que deve ser usado. Estão

 Os requisitos do usuário destinam-se às pessoas envolvidas.

 Os requisitos de sistema destinam-se a comunicar, as funções que o sistema deve fornecer.

 O documento de requisitos de software é a declaração aprovada dos requisitos de sistema.

MODELAGEM DE

ANÁLISE



Também chamada de:

O que é?

 Um conjunto de modelos sendo a primeira representação técnica do sistema.

 É uma forma textual e diagramática,

 _{fácil compreensão para mostrar a função, dados e}

os requisitos de dados

 _{Entender, fazer correções e revisar se está}

Por que é importante?

 Para validar requisitos de software, é preciso examiná-los de diferentes

pontos de vista.

 A modelagem da análise representa os requisitos em várias “dimensões”,

aumentando consequentemente a probabilidade de que sejam

 O modelo de análise e especificação de requisitos fornece meios para avaliar a

qualidade quando o software é construído

Análise de Requisitos

 Fornece ao projetista uma representação da informação, função e comportamento, podendo ser avaliado quando o software é construído.

 Essa é considerada a mais importante fase do ciclo de desenvolvimento de sistemas. O levantamento dos requisitos do sistema pode definir ou mais precisamente nortear o futuro do mesmo.

Objetivos

 1. Descrever o que o usuário requisitou, de maneira técnica;

 2. Estabelecer uma base para a criação do Projeto de

 Software;

 3. Definir um conjunto de requisitos que precisam ser

 validados quando o software estiver pronto.

Especificação de

Requisitos

 A especificação é o produto (consequência) da Análise de

Requisitos. Cada requisito exige uma especificação (como deve ser feito e como será validado);

 É o documento fundamental da Engenharia de Software,

pois especifica tudo O QUE deverá ser projetado e construído;

 Permite que o requisitos seja gerenciáveis (planejamento,

controle e feedback);

 A revisão dos requisitos é fundamental para garantir que

Modelos Predominantes

 A Análise é um conjunto de modelos que será a primeira representação técnica de um sistema. Os modelos predominantes são:

 Análise Estruturada (Metodologia Estruturada)

 Análise Orientada a Objetos (Met.Orienta a Objetos)



Modelagem de Dados: Definir os dados,

seus atributos e relacionamentos.



Modelagem Funcional: Definir como os

dados são transformados (processados)

dentro do sistema.



Modelagem Comportamental: Definir como

 Construir os modelos serve para que destaque ou enfatize as características criticas de um sistema, enquanto simultaneamente retiram a ênfase de outras características.

Modelagem de Dados

 O engenheiro define todos os objetos de dados processados no sistema.

 Objeto de dados é uma representação de quase toda informação composta que deve ser compreendida pelo software

Objeto

• _{Um objeto é um pedaço de software que possui seus}

atributos (estado) e métodos (comportamento).

• _{3 características principais} • _Estrutura • _{Comportamento} • _Identidade • _Concretos • _Abstratos

Exemplo de um objeto

 No caso um cachorro, que possui as seguintes propriedades e métodos:

 Propriedades : Cor do corpo : castanha cor dos olhos : preto, altura: 18 cm,

comprimento: 38 cm, largura : 24 cm

 Métodos : balançar o rabo , latir , deitar, sentar

Objeto de dados

 Pode ser uma entidade externa (algo que consuma informação)

 Pode ser uma coisa (um relatório ou mostrador)  Uma ocorrência (chamada telefônica)

 Um evento (alarme)

 Uma função (vendedor)

 Uma unidade, um lugar. Uma pessoa.  Pode ser representado por uma tabela

Ideia de Orientação a

Objetos

 Baseia-se em conceitos que aprendemos desde o jardim de infância;

 Objetos e atributos,  Classes e membros;  Todo e partes do todo;

Analise Orientada a

Objetos

 Enfoca que o sistema de software é uma coletânea de objetos que interagem entre si, realizando uma tarefa computacional, com características próprias, representadas por atributos (dados) e operações (processos);

 É uma forma mais próxima do homem para solucionar problemas do cotidiano.

AOO

 Examina um domínio de problema

definido como um conjunto de casos de uso em um esforço para extrair classes que definam o problema.

 Cada classe tem um conjunto de atributos e operações.

 Classes estão ligadas entre si através de diagramas UML

Quando usar OO



Quando o projeto é de grande porte.



Os requisitos não são totalmente fechados,

são vagos, incompletos ou inconsistentes.



É preciso novas aplicações.



Existe uma equipe com especialidades

Conceitos base da OO

 A OO introduz e enfatiza os seguintes conceitos: objeto, mensagem, classe, abstração, encapsulamento, herança, polimorfismo.

Programação Orientada a

Objetos (POO)



C++, C♯, Java, Object Pascal,

Objective-C, Python, SuperCollider, Ruby e

Smalltalk são exemplos de linguagens de

programação orientadas a objetos.

ActionScript, ColdFusion, Javascript,

PHP (a partir da versão 4.0), Perl (a partir

da versão 5) e VB.NET são exemplos de

linguagens de programação com suporte

a orientação a objetos.

Modelagens de Análise

 Além das que já foram citadas existem também outras como:

 _{Modelagem Baseada em Cenário}  _{Modelagem Orientada a Fluxo}

UML

 Unified Modeling Language (UML) é uma

linguagem de modelagem não proprietária.

 Permite que desenvolvedores visualizem os

produtos de seus trabalhos em diagramas padronizados.

 Auxilia a visualizar seu desenho e a comunicação

entre objetos.

 Os objetivos da UML são: especificação,

documentação, estruturação para sub visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem

Diagrama de UML