·
Engenharia Elétrica ·
Bases de Dados
Send your question to AI and receive an answer instantly
Recommended for you
7
Eng de Software e Banco de Dados - Caderno - P1 2 Solange - Poli-usp - Engenharia Elétrica
Bases de Dados
UMG
7
Unidade 3 - Banco de Dados Relacionais e Não Relacionais
Bases de Dados
UMG
4
Atividade Objetiva de Revisão - Regras de Associação
Bases de Dados
UMG
5
Av1 Banco de Dados Estácio 2023 - 1010
Bases de Dados
UMG
6
Prova Big Data Estacio
Bases de Dados
UMG
6
Questões 2 Sgbd Sistemas Banco de Dados
Bases de Dados
UMG
2
Avaliação Final Discursiva Banco de Dados Avançado
Bases de Dados
UMG
5
Questões 5 Banco de Dados
Bases de Dados
UMG
5
07 - Abordagem Relacional
Bases de Dados
UMG
6
Banco de Dados Relacional e Big Data - Prova
Bases de Dados
UMG
Preview text
09/03/2023 Software orientado a objetos os objetos colaboram entre si para realizar os funcionais dados do sistema Classe > Objeto | Atributos Operações Operação: - ação que um objeto pode realizar - não são executadas aleatoriamente - necessita de um estímulo para realizá-las Mensagem: - realiza a comunicação entre objetos - um objeto pede a outro que realize determinada ação Estado de um objeto - valores de seus atributos Abstração: - processo mental em que alguma coisa ou conceito é reduzida a suas características mais importantes relevantes para o problema - redução/gerenciamento da complexidade Encapsulamento: - a utilização do sistema deve depender de sua interface não de sua implementação - a interface funciona como intermediário entre os objetos 09/03/2023 Engenharia de Software e Banco de Dados # Engenharia de Software Definições: - Sistema: 1. Conjunto de partes que formam um todo complexo ou unitário; 2. Conjunto formado por um ou mais computadores, seus periféricos e programas utilizados. - Software: Programas de computador e documentação associada. Os produtos de software podem ser desenvolvidos para um cliente específico ou para um mercado geral. - Engenharia de Software: É uma disciplina de engenharia relacionada a todos os aspectos da produção de software. "O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione efetivamente em máquinas reais." Fritz Bauer Métodos: como fazer - planejamento e estimativas do projeto - análise de requisitos - projeto - codificação - teste e manutenção Ferramentas e Procedimentos: - sequência de aplicação das atividades dos métodos - produtos a entregar - controles para assegurar qualidade e coordenar mudanças 09/03/2023 Processo Evolução e crise do software / necessidade da eng. de software - Produtos amplamente distribuídos * + requisitos do usuário + linhas de código - Estimativas de prazo e de custos imprecisas * coletar dados sobre o processo de desenvolvimento de software * falta de indicação de medidas de produtividade para avaliar novas ferramentas e métodos. - Baixa qualidade do software * comunicação fraca entre cliente e desenvolvedor * alta taxa de erro - Baixa produtividade das pessoas da área de software Paradigma de Orientação a Objeto: - Objeto: * qualquer coisa é um objeto * objetos realizam tarefas por meio de requisições de serviços a outros objetos * cada objeto pertence a uma classe e uma classe agrupa objetos similares * a classe é um repositório para comportamento associado ao objeto * classes são organizadas em hierarquias 09/03/2019 - um objeto não tem acesso à implementação (método) do outro - permite que alterações internas no objeto não influenciam os demais contanto que o serviço (operação e seus parâmetros) sejam os mesmos - Polimorfismo: - capacidade de abstrair diferentes implementações em uma única interface - Generalização: - organização das classes em uma hierarquia - classes em nível mais alto são mais gerais e englobam as de nível mais baixo - classes em nível mais baixo herdam características das classes em nível mais alto - Composição: - objetos podem ser compostos por outros objetos. Desenvolvimento de Software: programação + modelagem - métodos - representação idealizada de um - processo sistema de software - ferramentas - perspectivas diferentes - modelos Vantagens: - gerenciamento da complexidade - comunicação entre pessoas envolvidas - redução de custo no desenvolvimento - previsão de comportamento futuro Modelo 09/03/2019 1. Gerenciamento de Requisitos: - Requisitos: necessidades que o software deve atender é definido para um domínio (abstração, necessidades...) é não estático; 1.1. Requisitos Funcionais: Definem funcionalidades do software 1.2. Requisitos Não Funcionais: Definem qualidades do software - Confiabilidade - Desempenho: - Estabilidade - Segurança - Usabilidade 2. Modelo de Casos de Uso (CU): - representa a funcionalidade do sistema - define o comportamento do sistema - associa necessidades dos stakeholders com os requisitos funcionais do sistema - composto por: 1. parte textual: descrição do caso de uso e atores 2. parte gráfica: diagrama de caso de uso 2.1. Descrição de Casos de Uso (Use Case): - duração de uma execução específica do sistema, do ponto de vista do usuário - não fala sobre a implementação do software - troca de eventos sequenciais entre atores e sistema - não há uma única forma de duração, mas é importante haver um padrão na documentação. 09/03/2019 2.2. Atores - algum externo ao sistema que interage com ele - envia e/ou recebe informação do sistema - geralmente iniciam a interação com o sistema - Representação em Diagramas de CU: - seta indica quem ou o que inicia a interação - segmento: qualquer das extremidades pode iniciar a interação (des. 1) CU1 CU2 CU3 (des. 2) Uma seta entre dois atores representa uma relação de hierarquia de classes. No caso, o ator 2 herda do caso de uso 1 e 2 do ator 1. = generalização 2.3. Relacionamentos entre CUs: - Inclusão (include): Um caso de uso em questão será copiado em outro(s) CUs (seta pontilhada apontando para o caso incluído) - Extensão (extend): Um caso de uso (o CU base) será exercido de um outro caso em um ponto de extensão (seta pontilhada apontando para o caso base) CU1 CU2 CU3 CU2 CU3 - execução - comportamento opcional ou condicional 3. Análise 3.1. Modelos da Fase de Análise: - modelo de casos de uso: visão do sistema sob o ponto de vista de seus agentes externos. - diagrama de classes: estrutura interna do sistema. - diagrama de interação: interação entre objetos para que o cenário de CU se realizem. - diagramas de estado e atividade. 3.2. Validação e Verificação dos Modelos: - Validação: é necessário para os quais o software estão sendo descrito estão sendo verificados. - Verificação: - O modelo construído está em conformidade com os requisitos do CU. 3.3. Regras de Negócio: - Políticas, condições, regras ou restrições que limitam a execução dos processos da organização - têm que ser coisas que serão controladas pelo sistema - devem ter um identificador para facilitar a referência a ela. Exemplo: - Quantidade máxima de inscrições por semestre letivo (RN01) Descrição: num semestre letivo o aluno não pode se inscrever em mais de 20 créditos. - Quantidade de alunos possíveis (RN02) Descrição: uma turma não pode ter mais de 40 inscritos. 16/03/2023 - Cliente deverá assinar o protocolo de recebimento (fora) e não é controlado pelo sistema. 3.4. Diagrama de Classes (UML): - descreve as classes, e as relações entre elas, do sistema - nessa etapa não são consideradas limitações impostas pela tecnologia usada. Exemplo: ContaBancária nome número saldo atributos dataAbertura criar() bloqeurar() desbloquear() de operacões debitar() - diferentes níveis de abstração: nome da classe nome da classe + atributos nome da classe + operação mostrar ou não os tipos das variáveis - Síntese de atributo: visibilidade nome: tipo [multiplicidade] = valo inicial - Síntese de operação: visibilidade nome (lista de parâmetros) : tipo de retorno 16/03/2023 - Visibilidade: Pública (+): qualquer objeto que tenha referência para a classe pode acessar. Protegida (#): só pode ser vista na classe em que foi criada e nas hierarquicamente abaixo. Privada (-): vista apenas dentro da classe em que foi criada. - Relacionamentos: - Associação Binaria: Classe 1 nome do vinculo Classe 2 multiplicidade Multiplicidade: Símbolo: Descrição 1 a 1: exatamente um 0 a 0..* zero ou muitos 1 a *: 1 ou muitos 0..1 zero ou um 1..*:1..* intervalo específico Exemplo Empregado Departamento 0..1 Organização Grupo papel (role) Indivíduo - É possível haver mais de uma associação entre duas classes (Empregado e Departamento: gerente e trabalhadores); podem haver auto associação (Empregado, supervisor e supervisionado). - Classes associativas são responsáveis por implementar o vínculo. São representadas por linhas pontilhadas entre a classe associativa e o vínculo. 16/03/2021 - Associação 'Genérica': Distribuidora |*| Produto (1) Distribuição (0..*| Cidade - Agregação e Composição: o Todo-parte o são assimétricas (A é parte de B, então B não é parte de A) o propagam comportamento (o comportamento do todo é equilibrado pelas partes). * Agregação - vínculo fraco, as partes podem existir independentes do todo e pertencem a vários 'Todos'. Exemplo: PáginaWeb |*| (1| Diretório | Imagem * Composição - vínculo forte, as partes não existem sem o todo e são exclusivas dele. Exemplo: Capítulo |*| Seção (1) (1..K| Parágrafo
Send your question to AI and receive an answer instantly
Recommended for you
7
Eng de Software e Banco de Dados - Caderno - P1 2 Solange - Poli-usp - Engenharia Elétrica
Bases de Dados
UMG
7
Unidade 3 - Banco de Dados Relacionais e Não Relacionais
Bases de Dados
UMG
4
Atividade Objetiva de Revisão - Regras de Associação
Bases de Dados
UMG
5
Av1 Banco de Dados Estácio 2023 - 1010
Bases de Dados
UMG
6
Prova Big Data Estacio
Bases de Dados
UMG
6
Questões 2 Sgbd Sistemas Banco de Dados
Bases de Dados
UMG
2
Avaliação Final Discursiva Banco de Dados Avançado
Bases de Dados
UMG
5
Questões 5 Banco de Dados
Bases de Dados
UMG
5
07 - Abordagem Relacional
Bases de Dados
UMG
6
Banco de Dados Relacional e Big Data - Prova
Bases de Dados
UMG
Preview text
09/03/2023 Software orientado a objetos os objetos colaboram entre si para realizar os funcionais dados do sistema Classe > Objeto | Atributos Operações Operação: - ação que um objeto pode realizar - não são executadas aleatoriamente - necessita de um estímulo para realizá-las Mensagem: - realiza a comunicação entre objetos - um objeto pede a outro que realize determinada ação Estado de um objeto - valores de seus atributos Abstração: - processo mental em que alguma coisa ou conceito é reduzida a suas características mais importantes relevantes para o problema - redução/gerenciamento da complexidade Encapsulamento: - a utilização do sistema deve depender de sua interface não de sua implementação - a interface funciona como intermediário entre os objetos 09/03/2023 Engenharia de Software e Banco de Dados # Engenharia de Software Definições: - Sistema: 1. Conjunto de partes que formam um todo complexo ou unitário; 2. Conjunto formado por um ou mais computadores, seus periféricos e programas utilizados. - Software: Programas de computador e documentação associada. Os produtos de software podem ser desenvolvidos para um cliente específico ou para um mercado geral. - Engenharia de Software: É uma disciplina de engenharia relacionada a todos os aspectos da produção de software. "O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione efetivamente em máquinas reais." Fritz Bauer Métodos: como fazer - planejamento e estimativas do projeto - análise de requisitos - projeto - codificação - teste e manutenção Ferramentas e Procedimentos: - sequência de aplicação das atividades dos métodos - produtos a entregar - controles para assegurar qualidade e coordenar mudanças 09/03/2023 Processo Evolução e crise do software / necessidade da eng. de software - Produtos amplamente distribuídos * + requisitos do usuário + linhas de código - Estimativas de prazo e de custos imprecisas * coletar dados sobre o processo de desenvolvimento de software * falta de indicação de medidas de produtividade para avaliar novas ferramentas e métodos. - Baixa qualidade do software * comunicação fraca entre cliente e desenvolvedor * alta taxa de erro - Baixa produtividade das pessoas da área de software Paradigma de Orientação a Objeto: - Objeto: * qualquer coisa é um objeto * objetos realizam tarefas por meio de requisições de serviços a outros objetos * cada objeto pertence a uma classe e uma classe agrupa objetos similares * a classe é um repositório para comportamento associado ao objeto * classes são organizadas em hierarquias 09/03/2019 - um objeto não tem acesso à implementação (método) do outro - permite que alterações internas no objeto não influenciam os demais contanto que o serviço (operação e seus parâmetros) sejam os mesmos - Polimorfismo: - capacidade de abstrair diferentes implementações em uma única interface - Generalização: - organização das classes em uma hierarquia - classes em nível mais alto são mais gerais e englobam as de nível mais baixo - classes em nível mais baixo herdam características das classes em nível mais alto - Composição: - objetos podem ser compostos por outros objetos. Desenvolvimento de Software: programação + modelagem - métodos - representação idealizada de um - processo sistema de software - ferramentas - perspectivas diferentes - modelos Vantagens: - gerenciamento da complexidade - comunicação entre pessoas envolvidas - redução de custo no desenvolvimento - previsão de comportamento futuro Modelo 09/03/2019 1. Gerenciamento de Requisitos: - Requisitos: necessidades que o software deve atender é definido para um domínio (abstração, necessidades...) é não estático; 1.1. Requisitos Funcionais: Definem funcionalidades do software 1.2. Requisitos Não Funcionais: Definem qualidades do software - Confiabilidade - Desempenho: - Estabilidade - Segurança - Usabilidade 2. Modelo de Casos de Uso (CU): - representa a funcionalidade do sistema - define o comportamento do sistema - associa necessidades dos stakeholders com os requisitos funcionais do sistema - composto por: 1. parte textual: descrição do caso de uso e atores 2. parte gráfica: diagrama de caso de uso 2.1. Descrição de Casos de Uso (Use Case): - duração de uma execução específica do sistema, do ponto de vista do usuário - não fala sobre a implementação do software - troca de eventos sequenciais entre atores e sistema - não há uma única forma de duração, mas é importante haver um padrão na documentação. 09/03/2019 2.2. Atores - algum externo ao sistema que interage com ele - envia e/ou recebe informação do sistema - geralmente iniciam a interação com o sistema - Representação em Diagramas de CU: - seta indica quem ou o que inicia a interação - segmento: qualquer das extremidades pode iniciar a interação (des. 1) CU1 CU2 CU3 (des. 2) Uma seta entre dois atores representa uma relação de hierarquia de classes. No caso, o ator 2 herda do caso de uso 1 e 2 do ator 1. = generalização 2.3. Relacionamentos entre CUs: - Inclusão (include): Um caso de uso em questão será copiado em outro(s) CUs (seta pontilhada apontando para o caso incluído) - Extensão (extend): Um caso de uso (o CU base) será exercido de um outro caso em um ponto de extensão (seta pontilhada apontando para o caso base) CU1 CU2 CU3 CU2 CU3 - execução - comportamento opcional ou condicional 3. Análise 3.1. Modelos da Fase de Análise: - modelo de casos de uso: visão do sistema sob o ponto de vista de seus agentes externos. - diagrama de classes: estrutura interna do sistema. - diagrama de interação: interação entre objetos para que o cenário de CU se realizem. - diagramas de estado e atividade. 3.2. Validação e Verificação dos Modelos: - Validação: é necessário para os quais o software estão sendo descrito estão sendo verificados. - Verificação: - O modelo construído está em conformidade com os requisitos do CU. 3.3. Regras de Negócio: - Políticas, condições, regras ou restrições que limitam a execução dos processos da organização - têm que ser coisas que serão controladas pelo sistema - devem ter um identificador para facilitar a referência a ela. Exemplo: - Quantidade máxima de inscrições por semestre letivo (RN01) Descrição: num semestre letivo o aluno não pode se inscrever em mais de 20 créditos. - Quantidade de alunos possíveis (RN02) Descrição: uma turma não pode ter mais de 40 inscritos. 16/03/2023 - Cliente deverá assinar o protocolo de recebimento (fora) e não é controlado pelo sistema. 3.4. Diagrama de Classes (UML): - descreve as classes, e as relações entre elas, do sistema - nessa etapa não são consideradas limitações impostas pela tecnologia usada. Exemplo: ContaBancária nome número saldo atributos dataAbertura criar() bloqeurar() desbloquear() de operacões debitar() - diferentes níveis de abstração: nome da classe nome da classe + atributos nome da classe + operação mostrar ou não os tipos das variáveis - Síntese de atributo: visibilidade nome: tipo [multiplicidade] = valo inicial - Síntese de operação: visibilidade nome (lista de parâmetros) : tipo de retorno 16/03/2023 - Visibilidade: Pública (+): qualquer objeto que tenha referência para a classe pode acessar. Protegida (#): só pode ser vista na classe em que foi criada e nas hierarquicamente abaixo. Privada (-): vista apenas dentro da classe em que foi criada. - Relacionamentos: - Associação Binaria: Classe 1 nome do vinculo Classe 2 multiplicidade Multiplicidade: Símbolo: Descrição 1 a 1: exatamente um 0 a 0..* zero ou muitos 1 a *: 1 ou muitos 0..1 zero ou um 1..*:1..* intervalo específico Exemplo Empregado Departamento 0..1 Organização Grupo papel (role) Indivíduo - É possível haver mais de uma associação entre duas classes (Empregado e Departamento: gerente e trabalhadores); podem haver auto associação (Empregado, supervisor e supervisionado). - Classes associativas são responsáveis por implementar o vínculo. São representadas por linhas pontilhadas entre a classe associativa e o vínculo. 16/03/2021 - Associação 'Genérica': Distribuidora |*| Produto (1) Distribuição (0..*| Cidade - Agregação e Composição: o Todo-parte o são assimétricas (A é parte de B, então B não é parte de A) o propagam comportamento (o comportamento do todo é equilibrado pelas partes). * Agregação - vínculo fraco, as partes podem existir independentes do todo e pertencem a vários 'Todos'. Exemplo: PáginaWeb |*| (1| Diretório | Imagem * Composição - vínculo forte, as partes não existem sem o todo e são exclusivas dele. Exemplo: Capítulo |*| Seção (1) (1..K| Parágrafo