PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS - AULA 02

Prévia do material em texto

Aula 2
Paradigmas de análise e projeto de software
Nesta aula, você irá:
Conhecer os conceitos e os principais paradigmas de análise de sistemas.
Conhecer a evolução histórica dos paradigmas de análise de sistemas, identificando os problemas de cada um, propiciando o surgimento do próximo.
Conhecer as principais características e ferramentas (modelos) das análises tradicional, estruturada, essencial e orientada a objetos.
O processo de desenvolvimento de Software
A tarefa de desenvolver software com qualidade não é fácil e demanda uma série de atividades com diferentes níveis de abstração, valendo-se de diferentes técnicas e propósitos. Conforme vimos nas aulas de PDS (Processos de Desenvolvimento de Software), o desenvolvimento de software requer algumas ETAPAS que, de acordo com a forma com que se relacionam entre si, originam os diferentes processos de desenvolvimento. 
Estudamos, ainda na disciplina PDS, alguns processos, dentre os quais podemos citar: Processo em Cascata Clássico, Processo em Cascata com Retroalimentação, Processo Iterativo-Incremental, Processo Prototipação, Processo Espiral, Processos Ágeis (como Extreme Programming – XP e Scrum) e RUP (Processo Unificado).
Os processos têm em comum a existência de etapas ou fases e diferem na forma como o sistema é desenvolvido e na integração e relacionamento entre as respectivas fases (ou etapas) do processo. Por exemplo, no processo em Cascata Clássico, os requisitos tinham que ser TODOS identificados na fase de análise (início do processo) e caso alguma mudança fosse necessária, não haveria possibilidade de ajuste, devendo congelar os novos requisitos identificados até que o conjunto inicial de requisitos estivessem implementados.
Já o Modelo Iterativo-Incremental divide os requisitos em partes e o sistema vai sendo construído aos poucos e as partes recém criadas vão sendo integradas às já existentes, repetindo este processo até que todos os requisitos do sistema estejam implementados.
De acordo com o processo de desenvolvimento e a forma de sua implantação nas empresas, podem acontecer pequenas variações nas fases (ou etapas). Em alguns processos, algumas podem ser agrupadas em única fase, outras podem ser suprimidas, mas de uma forma geral: análise, projeto e implementação tendem a existir.
Concepção ↔ Análise ↔ Projeto ↔ Implementação ↔ Testes ↔ Manutenção ↔ Implantação 
O contexto da análise de sistemas
A análise de sistemas é um das principais fases de um processo de desenvolvimento de software, qualquer que seja este. Geralmente, uma das fases iniciais. As principais atividades a serem desenvolvidas na fase de análise, onde é feito um estudo do problema, ou seja, estudo do sistema e do contexto em que está inserido (na organização) são: 
Identificar os requisitos do sistema, através do levantamento de dados com os usuários. Aqui, são usadas diversas técnicas, conforme as necessidades: entrevistas individuais, ou em grupo, questionário, reuniões planejadas, brainstorm, análise de documentos, visitas in locco (ou análise de campo), dentre outras.
Especificar O QUE o sistema deve fazer, em termos essenciais e com base nos requisitos identificados, ou seja, definir as funcionalidades que o sistema deve ter para atender ao que desejam seus usuários.
As definições da fase de análise independem de tecnologia, ou seja, são as soluções para o problema em estudo. É salutar que haja essa independência tecnológica para que a solução perdure no tempo, com diferentes possíveis implementações. Por exemplo, se fizermos uma solução lógica de divisão das partes do sistema dependendo de determinada linguagem de programação, amanhã, quando essa linguagem estiver obsoleta, a divisão terá que ser refeita. Se não houvesse tal dependência, mesmo que houvesse a troca da linguagem, a solução de análise continuaria a funcionar com várias tecnologias diferentes.
A tarefa de análise é desenvolvida pelos analistas de sistemas, que precisam ter ou desenvolver algumas aptidões, para conseguir lidar, de um lado, com o alto nível de abstração dos usuários e, de outro, com o alto nível técnico da equipe de desenvolvimento (projetistas, programadores, analistas de dados de dados, especialistas em redes, dentre outros).
A imagem (Relacionamento do Analista com usuários e equipe) mostra que o analista de sistemas precisa entender as necessidades e expectativas dos usuários a cerca do sistema e comunicar esse entendimento a equipe de desenvolvimento, através da especificação e modelagem do sistema.
Desde os primórdios da computação, a insatisfação dos usuários com o atendimento de suas necessidades e expectativas é causa de transtorno para os profissionais da área, sendo este mais um motivo para uma atenção efetiva do analista para com os usuários do sistema.
Usuário
⬇ Entendimento
Analistas de Sistema
⬇ Especificação
Equipe de Desenvolvimento
Os paradigmas de análise de sistemas
Os paradigmas que categorizam as técnicas e métodos usados na fase de Análise de Sistemas, conforme já explicado na aula 1, têm relação íntima com os paradigmas de programação que, por sua vez, ditam o estado da arte, posto que as linguagens de programação surgem antes das técnicas de análise e projeto de sistemas.
�
Todavia, ao escolher a técnica de análise a ser usada, conforme mostrou a imagem anterior, é feita, também, a escolha do paradigma da linguagem de programação que será usada, conforme ilustra a tabela.
Paradigmas de Análise x Paradigmas de LPs
�
paradigma da análise tradicional
A análise tradicional é a técnica que era usada na fase anterior ao surgimento da análise estruturada. Basicamente, produzia documento textual com a descrição do sistema e seus requisitos e, eventualmente, fazia uso de uma ferramenta bastante popular chamada fluxograma. A abordagem usada era exclusivamente voltada para a perspectiva das funcionalidades do sistema, mais especificamente dos programas (daí o uso dos fluxogramas).  Traçando um paralelo, no tempo, com os paradigmas de LPs, corresponde ao momento onde surgiam as linguagens de 3ª geração (alto nível), mas os programas não eram estruturados sob nenhum aspecto e os GOTOs (desvios incondicionais) eram usados em demasia.
Corresponde ao momento inicial da crise do software (anos 70), pois, a complexidade dos sistemas demandados crescia dia a dia e os programas escritos eram de difícil manutenção o que não facilitava as melhorias nos sistemas já desenvolvidos. Pouco havia de testes no processo de desenvolvimento, que ainda não estava formalizado e firmado como era necessário, ou seja, a qualidade do software era relegada ao segundo plano.
Paradigma da Análise Estruturada
Esse contexto, nada positivo, foi o pano de fundo para o surgimento (com esperança) da chamada análise estruturada, no início da década de 70, juntamente com as linguagens de 3ª geração (alto nível) ditas estruturadas, ou seja, que permitiam a escrita de programas com apenas 3 estruturas: sequencial, decisão e repetição, abolia o uso de GOTOs, surgia a programação modular com refinamentos sucessivos, ou top-down. Como os sistemas demandados aumentavam em complexidade, a técnica de análise estruturada trouxe a idéia da documentação do sistema através de diagramas, ou seja, de modelos que representavam a realidade. O reconhecimento da importância da modelagem de sistemas foi um marco muito importante no processo de desenvolvimento. 
Outra característica relevante foi a percepção da necessidade em se dividir o processo de desenvolvimento de sistemas em fases, em que cada uma representava um nível de abstração do sistema. Enquanto a sua percussora, a análise tradicional considerava apenas a perspectiva da análise funcional (como os processos funcionavam), a análise estruturada mostrou a importância de outra perspectiva fundamental: dos dados. O reconhecimento da importância dos dados gerou questionamentos do que era mais relevante: os dados ou as funções de um sistema?Mal se sabia que esse questionamento viria mais tarde a ser respondido pela análise orientada a objetos, que integrou as 2 perspectivas (funções e dados), mostrando que são igualmente relevantes.
A análise estruturada lançou mão de modelos gráficos para representar os requisitos e funcionamento. O principal modelo apresentado foi o DFD (Diagrama de Fluxo de dados); Segundo Edward Yourdon  Um DFD é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por “dutos” e “tanques de armazenamento de dados". O DFD mostra a visão  estruturada das funções que compõem um Sistema. Conforme ilustrado pela figura 4 (DFD em níveis), o DFD pode ter vários níveis de detalhamento (metodologia Top down ou refinamentos sucessivos).
�
 A cada nível, mais detalhes são inseridos. O DFD de contexto representa  o relacionamento do sistema com as entidades externas e  o diagrama de nível ZERO mostra as principais funções. Em um DFD, as funções são representadas por processos (representados pelos círculos), que quando não forem mais detalhados em outros níveis, devem ter sua lógica de funcionamento devidamente especificada, conforme ilustra a figura  5 (Especificação de processo).
�
O Dicionário de Dados (DD) é a ferramenta que complementa o DFD, explicando o conteúdo de cada um de seus elementos, conforme ilustra a figura 6 (Dicionário de dados).
�
Paradigma da análise essencial
Antes da Análise OO, que revolucionaria a forma de pensar e estruturar os sistemas e programas viria a análise essencial como uma evolução (melhoria) da técnica de análise estruturada, na tentativa de solucionar os problemas surgidos com a aplicação prática desta. Os principais problemas da análise estruturada eram:
Por onde começar a fase de análise? 
Não havia uma diretriz clara de como iniciar a modelagem na fase de análise. A decisão ficava a cargo dos profissionais, ditada pelas experiências desses profissionais. Ou seja, mostrava ser um processo de extrema subjetividade, como em geral são os processos analíticos que dependem dos seres humanos.
Separação entre aspectos lógicos e físicos, ao modelar o sistema: 
Dizia-se que o DFD devia ser um modelo lógico, sem considerar aspectos físicos (tempo, forma de fazer e etc). Mas esse era um conceito abstrato e muitas vezes não considerado. Na verdade, o que se desejava era se concentrar nos reais requisitos dos usuários, sem confundi-los com aspectos irrelevantes.
A identificação das principais funções do sistema (nível zero do DFD) era subjetiva e o mesmo sistema podia ter diferentes formas de agrupar e dividir funções, dependendo da visão de quem o modelava.
O DFD dava pouca ênfase a análise de dados, por isso, somente mais tarde, quando Peter Chain cria o MER (Modelo de Entidade e Relacionamentos), pouco antes do surgimento da análise estruturada, é que o modelo de dados foi incorporado à fase de análise.
Um DFD desenvolvido com a técnica de análise estruturada sempre é diferente se feito por profissionais diferentes, dada a subjetividade da técnica.
A Análise Essencial, também chamada de Análise Estruturada Moderna surgiu como uma estratégia de modelar o que o sistema deve fazer para satisfazer os requisitos dos usuários, partindo do princípio que dispomos de tecnologia perfeita, obtida a custo zero. Essa característica visa resolver o problema de número [2] - Separação entre aspectos lógicos e físicos, ao modelar o sistema. Ao separar a tecnologia e dando-a como perfeita, capaz de processar tudo, de armazenar tudo, sem custo, concentra-se no problema do usuário e com isso aumentar as chances de sucesso do sistema.
Para suportar a modelagem dos sistemas complexos e grandes, característicos daquele momento, a Análise Essencial não atendia plenamente. Ainda havia lacunas a serem preenchidas e estávamos no meio da crise do Software, onde o mercado clamava por uma metodologia de análise e projeto de sistemas mais efetiva, que apresentasse, na prática, melhores resultados. Em termos de programação, as pessoas já haviam aprendido a usar rotinas e funções de bibliotecas, otimizando o tempo de desenvolvimento, mas faltava algo mais, que pudesse aumentar o índice de aproveitamento de código e otimizar o desenvolvimento. A fase de manutenção também não apresentava resultados satisfatórios, com custos elevados, dispêndio de tempo excessivo e programas de baixa qualidade.
Estávamos no auge da crise do software e os problemas mais contundentes da época eram:
Duplicação de esforços na construção do software.
Dificuldade em estimar (poucos dados iniciais). 
Não cumprimento de prazos (cronograma) de desenvolvimento.
Alto Custo de desenvolvimento (tempo e mão de obra).
Software não atende aos requisitos.
Alto custo de manutenção.
Alto volume de documentação demandada pelos sistemas e dificuldade em mantê-los atualizados durante a fase de manutenção.
As pesquisas e desenvolvimento, em nível de linguagens de programação, já apontavam para as primeiras experiências com as linguagens orientadas a objeto. O conceito de objeto vem de encontro do que se precisa em termos de melhorias na implementação do código e potencializa a solução dos problemas que são apresentados a seguir, na medida em que:
Facilita o controle da complexidade inerente ao software.
Promove a reusabilidade --> componentes de código reutilizáveis.
Promove o desenvolvimento de sistemas de fácil manutenção, como consequência dos dois itens acima.
Paradigma da análise orientada a objeto (OO)
O paradigma orientado a objeto, doravante paradigma OO, trouxe uma grande revolução na forma de se pensar “o desenvolvimento de um sistema”, comparativamente ao paradigma antecessor, a Análise Essencial.  A visão de sistema, ilustrado na figura 10 (Mudança de Paradigma: Módulo x Objeto), até aquele momento visto como um “conjunto de módulos (partes, ou subsistemas) integrados”, passa a ser a de um “conjunto de objetos 
Mudança de Paradigma: Módulo x Objeto
�
X
�
Conforme ilustrado na imagem, ao passo em que na análise essencial (e estruturada) o sistema era visto sob duas perspectivas isoladas (procedimentos que realizam operações sobre os dados), na análise OO, os objetos possuem características próprias, modeladas por seus atributos (dados) e métodos (procedimentos) e as classes representam um conjunto de objetos com as mesmas características. Ou seja, houve uma integração entre procedimentos (agora chamados de métodos) e os dados (atributos) das duas perspectivas sobre as quais se modelavam os sistemas.
Classe encapsula dados e funções
�
Mais sobre análise orientada à objetos
Na prática, em termos de modelagem conceitual de análise, a tarefa principal passa a ser a identificação dos objetos (na verdade as classes) envolvidos no contexto do sistema. 
Ao identificar os objetos, naturalmente, modelam-se os atributos (dados que caracterizam o objeto) e os métodos (funcionalidades do sistema, inerentes aquele objeto ou classe). Na medida em que são identificados todos os objetos pertinentes a um sistema, já teremos os dados e procedimentos relacionados. 
Um modelo OO tem com entidade fundamental o Objeto, que recebe e envia mensagens, executa procedimentos e possui um estado que, por proteção apenas ele pode modificar. Problemas são resolvidos, por meio de objetos, que enviam mensagens uns aos outros.
Um Modelo OO é formado por quatro elementos básicos:
Objeto: É o principal elemento do modelo OO. Representa as “coisas” a serem modeladas do mundo real. Um objeto pode ser algo concreto como um carro, um aluno ou algo abstrato como uma disciplina. Cada objeto possui os dados inerentes a ele, como por exemplo, Nome (José) e Matrícula (201101272201) de um aluno e possui as operações que ele executa, como incluir novo aluno ou alterar dados de um aluno existente.
Mensagens: Quando um outro objeto deseja que seja executada uma operação, da responsabilidade de outro objeto, ele manda uma mensagema esse objeto, informando o que ele deseja que seja feito. A operação desejada será implementada por meio de um método.
Atributos: São dados que caracterizam o objeto.
Métodos : É um procedimento (implementado por uma rotina ou função) que executa uma operação em um objeto e define parte de seu comportamento.
Classes: É um conjunto de objetos com as mesmas características (atributos e métodos). Por exemplo, os objetos IX35 e Sportage são objetos da classe CARRO, cujas características em comuns são:
Atributos: modelo, fabricante, ano de fabricação, portas, dentre outros
Métodos: incluir carro, vender carro, dentre outros.
Dentre as principais características do paradigma orientado a objeto (OO), destacamos:
Encapsulamento: Encapsular significa esconder, ou seja, o objeto esconde seus dados do acesso indevido de outros objetos e somente permite que eles sejam acessados por operações implementadas pelos seus próprios métodos (funcionalidades que implementam o comportamento do objeto). Com isso, o encapsulamento protege os dados do objeto do uso arbitrário ou não intencional, o que pode ser visualizado na figura 12 (Encapsulamento). O encapsulamento é uma técnica para minimizar a interdependências entre as classes, pois apenas os métodos da respectiva classe podem alterar seus dados (atributos), facilitando a identificação de erros e a alteração dos programas.
Herança: Mecanismo para derivar novas classes a partir da definição de classes existentes através de um processo de refinamento. Uma classe derivada ou descendente herda os dados (atributos) e comportamento (métodos) da classe base ou ancestral ou ascendente. A implementação da herança garante a reutilização de código, que além de economizar tempo e dinheiro, propicia mais segurança ao processo de desenvolvimento, posto que as funcionalidades da classe base já foram usadas e testadas.
Polimorfismo: A palavra polimorfismo, deriva do grego e significa “muitas formas”. A partir do momento em que uma classe herda atributos e métodos de uma (herança simples) ou mais (herança múltipla) classes base, ela tem o poder de alterar o comportamento de cada um desses procedimentos (métodos). Isso amplia o poder do reaproveitamento de código promovido pela herança, permitindo que se aproveitem alguns métodos e se alterem (redefina) outros. Dessa forma um método com mesmo nome em classes distintas pode ter diferentes comportamentos. Por exemplo, pode-se usar a Herança para representar um relacionamento entre as classes Documento e Email, de forma que Email herda as definições (Atributos e métodos) de Documento. Suponha que um dos métodos de Documento seja Imprime. A classe email pode escrever novo código para o método Imprime, de forma que o email seja impresso de forma diferente do Documento. O método Imprime terá o mesmo nome, mas em cada classe se comportará de forma distinta.
O modelo de objetos surgiu (década de 80) como um modelo promissor para o desenvolvimento de software mais confiável devido as características inerentes ao modelo de objetos. Vejamos:
O conceito de encapsulamento permite a construção de classes independentes uma das outras, facilitando o desenvolvimento e a manutenção do software (alterações e melhorias na classe).
A herança e o polimorfismo permitem e facilitam a reutilização de código, útil na fases de implementação e manutenção.
O uso de técnicas orientadas a objetos facilita o controle da complexidade, uma vez que promove uma melhor estruturação de seus componentes e também permite que componentes já usados e validados possam ser reaproveitados. Cabe ressaltar que uma das principais razões para a baixa produtividade no desenvolvimento de software é a dificuldade de reutilização de código gerado pelos paradigmas de análise tradicionais. As hierarquias de classes (herança) são componentes portáveis entre aplicações, que, se bem projetados, podem ser reutilizados em vários sistemas sem modificação e, além disso, podem ser estendidos (polimorfismo) sem corromper o que já existe. Assim sendo, podemos dizer que o modelo de objetos proporciona modularidade trazendo os seguintes 
benefícios:
Reusabilidade: Softwares podem ser escritos com base em componentes já existentes.
Extensibilidade: Novos componentes de software podem ser desenvolvidos a partir de outros já existentes, sem afetar o comportamento do componente de origem.
Sabe-se que software são intrinsecamente complicados devido aos novos requisitos das aplicações modernas: alta confiabilidade, alto desempenho, desenvolvimento de software rápido e barato, alta complexidade e tamanhos grandes.
O modelo OO veio para combater os problemas derivados da crise do Software, termo cunhado em 1968 na Europa e caracterizado pelos seguintes problemas do software: baixa confiabilidade, baixa qualidade, alto custo de manutenção e duplicação de esforços na sua construção (tempo e dinheiro).
Um sistema desenvolvido com as características do modelo OO tende a ser bem estruturado, posto que os objetos são unidades coesas com interfaces simples que escondem as suas implementações.
No que se refere à forma de desenvolvimento, o que envolve o processo de desenvolvimento utilizado, o modelo OO permite uma melhoria substancial do processo de construção de software em relação aos paradigmas tradicionais (tradicional, estruturado e essencial). A chave da análise OO é o foco em objetos (e em classes) e não em funções. O início da fase de análise não se dá mais pela identificação das diferentes funcionalidades do sistema e sim pela identificação dos objetos que compõem o sistema.
Inicialmente, vários especialistas criaram diferentes diagramas de análise e projeto OO. Num dado momento, tais profissionais se juntaram e com o melhor de cada um criaram uma linguagem de modelagem orientada a objeto, nascia a UML (Unified modeling language), cujos principais diagramas eram:
Diagrama de Casos de Uso.
Diagrama de Classes.
Diagrama de sequencia.
Diagrama de Atividades.
Diagrama de Implementação.
Diagrama de Componentes.
Nesta aula, você: 
Sobre os paradigmas de análise: tradicional, estruturado, essencial e orientado a objeto;
A contribuição de cada modelo para o processo de desenvolvimento de software;
As características e principais modelos de ferramentas de cada paradigma de análise de sistemas.
Registro de Participação
Com relação a fase de análise de qualquer processo de desenvolvimento de software, analise as assertivas a seguir:
É uma fase onde identificamos os requisitos do sistema, ou seja, aquilo que o usuário precisa que o sistema faça.
É uma fase onde se especifica COMO fazer.
É uma fase que independe de tecnologia, mas que já temos que saber a linguagem com que desenvolveremos.
Sabermos a linguagem é fundamental para sabermos o paradigma de análise que usaremos.
É uma fase independente de tecnologia, para que a solução possa ser implementada de várias formas.
Com base em sua análise, assinale a alternativa correta:
 
 1) Estão corretas as opções I e V 
 2) Estão corretas as opções I, II e V 
 3) Estão corretas as opções I, III e V 
 4) Estão corretas as opções I, IV e V 
 5) Estão corretas as opções I, II, IV e V 
 
2. Sobre a análise estruturada, assinale a ÚNICA opção falsa:
Foi o primeiro paradigma de análise a usar diagramas para representar o funcionamento do sistema. 
Surgiu num momento em que o software crescia de complexidade e via sua primeira crise. 
Surgiu na época da programação orienta a objeto. 
O processo de análise era segmentado: funcionalidade e dados em duas perspectivas distintas. 
 
3. Sobre a análise essencial, assinale a ÚNICA opção correta:
Revolucionou a forma de pensar sistemas, usando modelos distintos do paradigma antecessor. 
Trouxe uma grande contribuição ao mundo: a lista de eventos, facilitando a atividade inicial do processo de análise de sistemas 
Surgiu numa época em que o software vivia sua era de ouro, onde os principais problemashaviam sido resolvidos 
Os principais modelos usados eram: DFD, DD, especificações dos casos de uso e diagrama de hierarquia entre os módulos. 
 
4. Sobre os conceitos inerentes ao paradigma orientado a objeto, analise cada assertiva abaixo e classifique-as como Verdadeira ou Falsa:
O conceito de encapsulamento é a base do modelo OO, permitindo que os atributos de um objeto sejam protegidos e só possam ser alterados pelos métodos do próprio objeto.
O conceito de herança e polimorfismo facilita a reutilização de código.
Objeto é um conjunto de classes com as mesmas características, por exemplo, os objetos Flamengo e Vasco são da classe Times.
O modelo OO trabalha como o modelo essencial, ou seja, com as perspectivas de dados e funções de forma isolada.
Assinale a opção que apresenta a correta sequencia de V e F:
 1) V, V, F ,F 
 2) V, V, V, F 
 3) V, F, V, F 
 4) F, F, V, V 
 5) V, F, F, V 
 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS � PAGE �1�
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS � PAGE �1�