Details
Nothing to say, yet
Comment
Nothing to say, yet
Listen to Aula1_Eng_Sist_Software_Tipos_Modelagem by Marcelo B Santiago MP3 song. Aula1_Eng_Sist_Software_Tipos_Modelagem song from Marcelo B Santiago is available on Audio.com. The duration of song is 31:43. This high-quality MP3 track has 254.463 kbps bitrate and was uploaded on 20 Mar 2024. Stream and download Aula1_Eng_Sist_Software_Tipos_Modelagem by Marcelo B Santiago for free on Audio.com – your ultimate destination for MP3 music.
Comment
Loading comments...
This is a transcription of a lecture on Systems Engineering. It covers topics such as requirements, analysis, design, testing, and quality. The lecture emphasizes the importance of good software engineering practices and teamwork. The objectives of the course are to teach students how to build efficient and high-quality software products. The lecture also discusses the different components of a computerized information system and the differences between systems engineering and software engineering. It concludes with an overview of functional modeling and the IDEF zero model. Aula 1, Projeto de Sistemas. Apresentação e visão geral, os tópicos a serem abordados é a apresentação do curso e visão, processo e gestão requisitos, análise, projeto, teste, qualidade. Perceba aqui, requisitos, análise, projeto, teste e qualidade. Aqui é o rapito, o rapito que o professor falou. Então vamos lá. Projeto de sistema, emenda, processo e seu gerenciamento, análise de requisitos de software e de sistemas, o projeto de implementação de software, modelagem orientada a objetos e UML e estudos de caso. Então a motivação, como desenvolver um sistema de software correto, eficiente, barato e com fácil manutenção e alteração. Alguém organizado que sabe trabalhar em equipe pode ser um ótimo projetista de sistemas, também chamado neste curso de engenheiro de software. Um software desenvolvido por uma equipe sem nenhuma boa prática em engenharia de software, ele irá funcionar, mas de difícil manutenção. Já o desenvolvimento por uma equipe com as melhores práticas, conceitos de engenharia de software, com vários modelos, boa especificação, terá uma manutenção melhor. Objetivos do curso, então, é propiciar ao aluno mecanismos para a construção de produtos de software, eficientemente, que atendem aos padrões de qualidade, confiabilidade e economia de recursos. Vamos lá então. Modelos de projetos. O projeto de sistemas trata especificamente de como você organiza o código. Se você faz uma documentação muito bem feita, nessa fase de projeto, pega essa documentação e terceiriza para uma fábrica de software. Isso é possível, mas a especificação terá que ser muito bem feita. A cada novo processo, você faz um novo levantamento de requisitos de software. Existe um waterfall, cascata, que passa por uma única vez nessas fases do rápido. Mas, nesse processo, dificilmente é aplicado com um bom êxito. Em alguns casos específicos, o waterfall, cascata, é bem utilizado, mas na maioria dos casos não. Rapito é o ciclo de vida de desenvolvimento do software, sendo que o R do rapito é requisitos, o A é análise, o P é projeto, o I é implementação, o T é o teste e o O é operação e implantação. Ok? Vamos então continuando. Vamos lá. Modelos funcionais. O IDF zero, diagrama de casos de uso e diagrama de fluxos de dados. Então, ainda sobre o modelo, os modelos funcionais, né? O foco desse curso é o levantamento de modelagem. Aqui é o levantamento de modelagem para o levantamento de requisitos, que chamamos de modelagem de análise. Quando tiver muitos termos técnicos, que o seu cliente não consegue entender, aí passa a ser chamado de modelo de projeto. Contextualização. Então, novamente, o rapito é requisito, o R, A de análise, P de projeto, I de implementação, T de teste e O de operação. Rapito. Um sistema para fazer um bolo. Entradas, farinha, açúcar, ovos, manteiga, tempo, gás, receita do bolo, cozinheiro, saídas, um bolo. Então, processamento, junte a farinha, os ovos, asse, 40 minutos, enfim. E realimentação, cozinheiro controla a temperatura do forno constantemente. Isso é um sistema que tem entrada, processamento e saída. Sistema de informação. O que é? O sistema de informação, ele estuda a computação como atividade meio. Ciência da computação, engenharia de computação, engenharia de software, estuda a computação como atividade sim. Então, de novo, sistema de informação estuda a computação como atividade meio, enquanto ciência da computação, engenharia da computação, engenharia de software, estuda a computação como atividade sim. Sistema de informação. É um conjunto de elementos ou componentes interrelacionados que coletam entrada, manipulam e armazenam o processamento e disseminam, que é a saída, os dados e a informação e fornecem mecanismos de realimentação para atingir um objetivo. Pode ser manual, o exemplo no caso do bolo, e o exemplo antigo do correio, tudo manual. Então, como é que acontece isso? Você tem a entrada dos dados, o processamento dos dados e a informação, que é a saída, ou seja, e depois existe uma realimentação na entrada e o processo ele continua assim por diante. Componentes de um sistema de informação computadorizado. Bom, vamos lá, é o hardware, software, pessoas, telecomunicação, BD, que é o banco de dados e procedimentos. Esse sistema está no escopo de uma empresa, envolvendo vários processos organizacionais. No caso do software, são programas que estão ligados a dados e interfaces e por dentro você tem a documentação dele. Os programas de dados e interfaces se relacionam. É possível ter a documentação do software em dois níveis. 1. A documentação para o desenvolvimento do software e 2. A documentação para o uso do software, que seria o guia do usuário. Diferenças entre engenharia de sistemas versus ES. Vamos lá, sistemas de informação, engenharia de sistemas e análise de sistemas, são termos correlatos. A diferença entre engenharia de sistemas versus ES, que é a engenharia de software. Vamos lá, engenharia de sistemas, ele está no diagrama de Venn, na esquerda, e do outro lado do diagrama de Venn, está a engenharia de software. Então, esses dois mundos se relacionam. Uma observação, problema existente no aprendizado de desenvolvimento de sistemas, software, é que não existe convergência de palavras usadas pelos autores de livros didáticos. Então é isso, são termos correlados. Sistemas de informação, engenharia de sistemas e análise de sistemas, são termos correlados. Ainda sobre as diferenças de engenharia de sistemas versus engenharia de software, aqui a gente tem a fonte que é o currículo de referência da ACMCC e EEESS, o Computing Curricula CC 2020. Então, vamos lá, você tem aqui, pós 1990, o EE, que é o Engenharia Elétrica, CE, Engenharia de Computação, o CS, que é o Ciência da Computação, o Science Computer, o SE, que é o Engenharia de Software, Software Engineer, o IT, que é o Technology Intelligence, ou Tecnologia da Informação, e o Sistema de Informação, que é o IS, ok? Então, vamos lá, o EE e o CE, que é o Engenharia Elétrica, Engenharia de Computação, é o Hardware, o Software, ele já é Engenharia de Computação, Ciência da Computação, Engenharia de Software, e o IT e o IS, que é o Tecnologia da Informação, Sistema da Informação, são as necessidades organizacionais, ok? E aí você tem a evolução para mais um novo modelo, né, que já complementa todas essas fases, né, juntando com a segurança também da informação, ok? É a atividade do domínio, né, habilitada para a computação, computação tecnológica, e as fundações para a computação, que envolve o hardware, o software, e as necessidades organizacionais, ok? A evolução do modelo CC 2020, esse gráfico que parece um caos, né, dentro, tudo ligado, né, com várias caixinhas do IT, SE, CS, CE, IS, DS e o CSEC, que é a Segurança, representa a realidade de tudo relacionado à computação. Engenharia de Sistema é o uso de técnicas, processos e pessoas com várias especialidades para desenvolver sistemas e organizações com as atividades, com as seguintes atividades, definição de requisitos, que é um, dois, projeto e modelagem, né, aqui o exemplo é o DFD, que é o Diagrama de Fluxo de Dados, ou o IDF, né, e os casos, o Diagrama de Caso de Uso, e o DER, que é o Diagrama de Entidade e Relacionamento. Isso daqui tudo, né, ele é usado na fase de projeto e modelagem. Tudo isso é para levantar requisitos funcionais do sistema, é importante ver isso na hora que você for ver aquele monte de diagrama lá. Então vamos lá, continuando, três, desenvolvimento de subsistemas, quatro, integração, cinco, instalação, seis, evolução e sete, desativação. Essas fases podem ser vários modelos prescritivos ou processos, metodologia de software, ok? Mas a essência é, entenda, planeje, execute e examine. Essência de qualquer coisa, entender, planejar, executar e examinar. Então, novamente, bem importante aqui, engenharia de sistema é o uso de técnicas, processos e pessoas com várias especialidades para desenvolver sistemas e organizações com as seguintes atividades, um, definição de requisitos, dois, projeto e modelagem, três, desenvolvimento de subsistemas, quatro, integração, cinco, instalação, seis, evolução e sete, desativação. Como fazer a análise de sistemas? Um, criar um grupo de participantes que deve conduzir a análise de sistemas. Dois, coletar os dados e requisitos apropriados. Três, analisar os requisitos e dados coletados. Quatro, elaborar um relatório sobre o sistema antigo, sobre os novos requisitos e sobre as propriedades de projeto. Isso é como se faz, então, análise de sistemas. Rapidamente, um, criar um grupo. Dois, coletar os dados e requisitos. Três, analisar. Quatro, elaborar um relatório. Propriedades de um sistema. Propriedades, então vamos lá, propriedades funcionais. Verifica se o sistema está funcionando corretamente, segundo seus requisitos. Não funcionais são características de confiabilidade, desempenho, segurança e etc. Observação, um sistema é formado por componentes interligados. Os componentes isoladamente pode funcionar corretamente, porém, quando integrados isso pode não ocorrer. Isso vale para qualquer característica não funcional. Apresentação de alguns modelos não funcionais. Modelagem do sistema IDEF zero. IDEF zero. Lembre-se que tudo isso é para levantamento de requisitos, que a gente já tinha comentado. Então, o IDEF zero. Você tem, então, um meio, aqui você tem um gráfico, que ele tem no centro o nome da função, depois ele tem a entrada, que é o input, e a saída, que é o output. No meio, em cima, está o control, que são as regras. Embaixo, o mecanismo, que são os recursos. Então, input, entrada de dados, output, saída de dados. Em cima estão as regras, embaixo os recursos. Ok? Em cima o control, embaixo o mecanismo, ou mecanismo, em inglês. O IDEF zero, Integration Definition for Function Modeling, é uma modelagem hierárquica e funcional do sistema, tendo entradas, saídas, regras, controls e recursos, mecanismo. No nível zero, existe apenas um processo. Então, aqui é outro exemplo, de como é que funciona isso. Ele colocou um exemplo aqui, de um atendimento no plano de saúde, ok? Mas, não vale a pena falar. Talvez, só frisar, que cada processo pode ter outros sub-processos, até você detalhar, até o último nível de todo o sistema. Outros modelos funcionais. Dois, diagrama de casos de uso. Ele é formado por casos de uso, ele simboliza os cenários do sistema. Então, ele tem atores, que não faz parte do sistema ser criados, e relacionamentos. Então, você tem o ator, que ele se relaciona com os casos de uso, ok? Então, trata-se de um diagrama simples, o ator pode ser uma pessoa, ou outros sistemas que alimentam o seu sistema, e pode ter os relacionamentos também, tá? Esse diagrama é composto de vários casos de uso, vários atores e vários relacionamentos. É comum confundir cada caso de uso, como um diagrama de casos de uso, e não é. Cada caso de uso é um elemento do diagrama de casos de uso, ok? Continuando, vamos com estereótipos em casos de uso. Include realização obrigatória de outro caso de uso. Extenda. O fluxo pode ir para outro caso de uso. Então, os casos de uso podem se relacionar com o uso de estereótipos. Então, a gente tem aqui o seguinte gráfico, tá? Ou o diagrama. O faz-pedido, então, tem um comando chamado extend, que ele está entre o faz-pedido, né? A elipse do faz-pedido, até a elipse do consulta-cpf, e o faz-pedido, ele está ligado com uma seta até o gera-nota-fiscal, que também é o gera-anf, né? Que também é uma elipse. Então, nós temos três elipses em que o faz-pedido, ele vai, ele tem uma seta até o gera-nota-fiscal, e o consulta-cpf tem uma seta que vai até o faz-pedido. Então, faz-pedido, ele não tem seta para o consulta-cpf. E o extend é o estereótipo. Include é o estereótipo, ok? Então, isso daqui é uma modelagem, né? De você ter esses três elipses, assim. Cada elipse dessa é como um conjunto de códigos que devem ser criados. Esses códigos elipses têm que ser bem especificados antes de começar a codificar. É como especificamos cada caso de uso elipse, através de um template. A parte mais trabalhosa é detalhar o que faz cada caso de uso, ok? Então, gente, modelagem é você montar esses diagramas, né? Então, novamente, quando a gente falou que o projeto de modelagem usa diagrama de fluxo de dados, diagrama de casos de uso, diagrama de entidade de relacionamento, né? Tudo isso é para levantar requisito funcional. Então, é só isso, entendeu? A modelagem, quando você fala, é isso. Deixar o sistema bem, assim, especificado, né? Para que esse projeto possa ser encaminhado para a próxima fase. Bom, vamos lá, então. Diagramas de casos de uso. Ainda continuando com esse tema. Ele descreve a funcionalidade do sistema, descrição dos eventos necessários para conseguir o comportamento exigido de casos de uso e é descrito em termos do quê? Linguagem do domínio, né? O sistema deve fazer e não como, né? A implementação, né? Que o sistema deve fazer. Então, sempre focado do quê, né? A linguagem. O sistema deve fazer e não como, né? Ele deve fazer. Isso foi uma briga bem antiga que eu tive com uma menina da área de TI, lá do telebanco, em que ela falou que eu tinha que só pedir o que eu queria, mas a forma de fazer ela não tinha que falar para mim. Lembra disso? Foi. Então, aqui, o que ela quis dizer foi o seguinte, você tem que se preocupar no que você quer, mas o como é comigo, ok? Beleza. Bom, características, gente, dos diagramas de casos de uso. Eles captam o comportamento desejado. Permite enxergar e documentar os requisitos. Estrutura simples. Pode ser usado em todas as fases do desenvolvimento do sistema. Um dos princípios, né? Do RUP, é centrado nos casos de uso. Tudo gira em torno de casos de uso. Bom, vamos lá agora. Fluxo de eventos. Aqui, igual, documentação dos casos de uso, ok? É usado para descrever um caso de uso e não descrever um diagrama de casos de uso. Ele é usado para descrever um caso de uso e não escrever o diagrama total com vários casos de uso. Ok? É aquela elipse. Então, por exemplo, um modelo detalhado, né, você tem o fluxo de eventos de casos de uso para o nome do caso de uso, né, por exemplo, fazer pedido, que era o caso da elipse. Aí você tem o X1, objetivo, X2, atores, X3, pré-condições, X4, fluxo principal, X5, subfluxos, se aplicável, e o X6, fluxos alternativos, né, onde X é o número de casos de uso, ok? Para cada elipse, você faz uma documentação como essa. Fluxo de eventos, né, novamente, documentação dos casos de uso. Fluxo de evento de alto nível. Faz um levantamento preliminar das necessidades do sistema, sem se aprofundar nos detalhes. Então, alto nível, não se aprofunda. É usado para se ter uma visão geral de todos os requisitos do sistema. Então, especificando, né, mantém clientes, por exemplo. Objetivo, manter os clientes da empresa onde também serão submetidos a análise de crédito. Os clientes devem fornecer informações como referências pessoais e comerciais, dados profissionais e pessoais. O ator, analista de crédito. Então, aqui, para descrever o escopo, você usa, então, essa forma, né, de fazer o levantamento preliminar das necessidades, mas de forma de alto nível. Você não entra em detalhes aqui no objetivo, ok? A sugestão é juntar os fluxos de eventos de alto nível e detalhado em um único fluxo de eventos, tá? É isso. Fluxo de eventos, documentação ainda, né, dos casos de uso. Então, a gente tem um exemplo aqui, tá? A gente tem o fluxo de eventos de caso de uso para seleção de cursos administrar. 1.1. Pré-condições. O subfluxo, acrescentar uma oferta de curso do caso de uso, manutenção de informações de curso, precisa ser executado antes que esse caso de uso se inicie. Fluxo principal, 1.2. Esse caso de uso começa quando o professor registra no registro de cursos e entra com sua senha. 2. O sistema verifica se a senha é válida, aí você coloca lá o código E1, que vai ter uma explicação, e pede ao professor para selecionar o semestre atual ou um semestre futuro, E2. Quem quer o E1? O E1 é uma exceção e o E2 também é outra exceção, ok? Vamos lá. 3. O professor entra com o semestre desejado. O sistema pede ao professor para selecionar a atividade desejada. Por exemplo, ABD, Delete, Review ou Add, Delete, Review, Print ou Quit. Se a atividade selecionada for Add, será realizado o subfluxo S1, acrescentar uma oferta de curso. Se a atividade... 1.3. Subfluxos. Acrescentar uma oferta de curso. O sistema exibe a tela do curso contendo um campo para nome e número de curso. O professor entra com o nome e número de curso, E3, que é outra exceção. O sistema exibe as ofertas de curso para o curso fornecido, E4, outra exceção. O professor seleciona uma oferta de curso. O professor vincula o professor à oferta de curso selecionado. Aí vem o E5, também tem caso de exceção. O caso de uso começa de novo. Então, aí você tem no S2, ainda no subfluxo, apaga uma oferta de curso, revise uma agenda, imprime uma agenda, ok? Tudo isso o sistema tem que fazer. E os fluxos alternativos, que seria o 4 agora. Um número de ID inválido e o professor é fornecido. Então, o usuário reentra com o número do ID do professor ou encerra o caso de uso. E2, que aqui seriam já esses fluxos alternativos, é a explicação das exceções. Então, E1, que é a questão do ID, e o E2 é fornecido um semestre inválido. Então, o usuário pode reentrar com o semestre ou encerrar o caso de uso. Então, isso daqui é um exemplo de um fluxo de eventos, documentação dos casos de uso. Outros modelos funcionais. A gente tem um diagrama de fluxo de dados. É formado por processos, que simboliza os cenários do sistema, entidades que interagem com o sistema, banco de dados que armazena dados, que é igual tabelas, e fluxo de dados, que são dados fluindos pelo sistema. Então, aqui a gente tem entidade externa, que são os atores no caso de uso. E esse retângulo, entidade externa, está conectado até a elipse processo por meio de uma seta. E nessa seta tem um indicativo como fluxo de dados. E esse processo, após ser processado, ele entra no D1, que é o depósito de dados. Você não tem um banco de dados no diagrama caso de uso. O DFD, que é o diagrama de fluxo de dados, só modela os processos e banco de dados. Já o caso de uso, só modela processos e atores. É importante isso. Diagrama de fluxo de dados ainda, o DFD, pode ser construído de forma hierárquica, como o IDF-0, ou por cenário. Um cenário é uma situação que ocorre no sistema. Como um aluno faz matrícula. Uma observação interessante é que os diagramas mais detalhados no hierárquico acabam convergindo para os por cenário. Então, aqui a gente tem um exemplo de um DFD, que os processos se relacionam, quebrem mais processos, mas sempre com aquele processo de entrada, saída, processo, eles podem explodir mais dois, mais três, e aí vai. Até a parte mais detalhada, que é o último nível. No último nível, pode ter a especificação de um caso. Modelos de dados ainda, falando nele. Agora a gente está falando do diagrama de entidade relacionamento, que também é um modelo de dados, é um tipo de modelo de dados. Aqui ele é mais complexo, tem muitas coisas nele. Tem elipses, que são conectados, interlacionados. Tem aqui losangos, retângulos, todos conectados, interlacionados. Interessante. E aí a gente tem também... Agora a gente vai falar sobre classificações de sistemas de informação. Então, a gente tem aqui os sistemas de processamento de transações, que é o SPT. A gente tem os sistemas de informações gerenciais, que é o SIG. Sistemas de suporte à decisão, que é o SSD. Sistemas especialistas e de inteligência artificial. E uma observação aqui. Existem outras classificações de software do sistema, de aplicação científica e de engenharia, embutido. Embutido, aplicações web, legado etc. Então vamos lá. O SPT dos sistemas que ele falou, ele baixa a complexidade, manipula muitos dados. Um algoritmo simples, tipo aquele sistema que a gente usava na CAP. Ele entra muita informação e vai indo. O SIG não. Ele terá todas as informações do SPT, mais informações de cada loja, por exemplo. Então ele gera informação gerencial, certo? O SSD, que são sistemas com algoritmos bem complexos, que eles preveem local de instalação, de nova filial, etc. É um sistema um pouco mais elaborado, ok? Bom, motivação sobre software. O que é software? É uma sequência de bits que o cliente compra para automatizar algum processo na sua empresa. Assim, software é quase ilimitado. A capacidade do HD é grande, porém tempo e dinheiro são escassos. O ES, que seria o Engenharia de Software, é uma forma organizada de produzir esta sequência de bits, satisfazendo as necessidades do cliente. Gente, só lembrando que toda vez que você tem uma escassez de tempo e recurso financeiro, isso acaba inviabilizando o sistema de qualidade. Software de computador, organizado. Como fazer com qualidade? Baixo custo, a curto prazo, etc. Engenharia de Software é a área da ciência que estuda processos, métodos, técnicas e ferramentas para pessoas que constroem software com qualidade, correto, eficiente, fácil manutenção, etc. Formas de construção, então, dos softwares. Softwares genéricos, editores, o SGBC, o CASE, etc. Software sob encomenda, desenvolvido especificamente para um cliente. Esta classificação não é rígida, como o ERP, Enterprise Resource Planning, ou Sistema Integrado de Gestão Empresarial, que é customizado para empresas. Ideal em ambos os casos, software formado por componentes reutilizáveis. Bom, agora a gente tem um gráfico, um gráfico que fala realmente do rapido. Na verdade, no eixo x ele tem o tempo, que é a definição, manutenção, tempo, pela taxa de falhas. Então, ele é um gráfico exponencial, onde a parte superior está no eixo y, na taxa de falhas, e ele faz aquela curva, e vai descendo até o eixo x, na operação, porque ele demonstra a operação, e vai diminuindo, vai se encostando cada vez mais na manutenção. Então, no início, o mundo real, muitos problemas, novos planejamentos, você tem essa curva aí. No mundo ideal, com taxa de falha. Quanto mais tempo, no começo sempre tem falha no sistema, no software. Taxa de falha. Então, você implantou, até ele ficar redondinho, vai demorar um pouco. E aí você vai passando o tempo, vai passando o tempo, a operação vai funcionando, vai pedindo, abrindo aqueles... Lembra que a gente abria várias ocorrências para a correção do sistema? Então, isso vai corrigindo o sistema, até chegar no nível ideal, que ele funcione corretamente. Bom, aqui o professor colocou um exercício da clínica, de diagnóstico e tal, onde tem todos esses processos. E aí a gente vai falar isso, então, no próximo slide, ou na próxima aula, final da aula.
There are no comments yet.
Be the first! Share your thoughts.
