Padrões Essenciais em Análise de Sistemas

CAPÍTULO 2 Padrões essenciais em análise de sistemas Ao elaborar a análise do sistema, uma lista de requisitos é necessária, mas, jamais se encontra alguém que venha a possuir todos eles (cada usuário tem uma necessidade específica, ou requisito, que tem que ser atendido pelo sistema). Mesmo assim, esta abordagem não pode ser esquecida, e conciliá-la o máximo possível à presença destes requisitos é importantíssimo na análise do sistema. Numa abordagem geral, destacamos requisitos que você tem que ter para analisar um sistema com a melhor preparação possível objetivando um sistema de boa confiabilidade técnica e organizacional: concentração, persuasão, autoconfiança, ação conciliadora, espírito de grupo, sensibilidade, persistência, determinação, flexibilidade, percepção, clareza de raciocínio, simplicidade, comunicativo, iniciativa e criatividade. Algumas diretrizes de conduta também são destacadas: » Procure ser aceito profissionalmente, do nível mais alto ao mais baixo da empresa. » Tente entender o que o usuário “quer dizer” e não o que “você pensa” que ele quer dizer. » Escute muito primeiro, fale muito pouco depois. » Esteja sempre familiarizado com os últimos progressos da tecnologia da informação e compreenda como aplicá-los na sua empresa. » Seja capaz de explicar conceitos complexos em termos simplificados. » Não se esconda em jargão de informática; fale a linguagem da empresa. » Conheça a área de negócio para a qual desenvolverá sistemas, passando boa parte de seu tempo com o usuário. » Sugira soluções inovadoras aos requisitos de informação e desenvolva com clareza, analisando sempre a relação custo X benefício, utilizando alternativas viáveis. Trecho extraído do artigo do professor Luiz Angelo – produzido para o curso técnico da ETEC de Avaré - SP. UNIDADE II | ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS O que é análise de sistemas? Conforme o dicionário Michaelis, análise deriva do grego análysis, que significa: decomposição ou separação de um todo, quer seja uma substância material quer seja um produto do pensamento, em seus elementos constituintes. Por Análise de Sistemas (AS) entende-se a atividade inicial do processo de desenvolvimento de sistemas em que se determina e especifica o que um sistema deve fazer, bem como as circunstâncias sob as quais deve operar, envolvendo um esforço colaborativo entre analistas de sistemas e usuários. Atualmente o termo análise de sistemas é por vezes substituído pelo termo engenharia de requisitos, como parte desse conceito maior. A análise de sistemas é, em última instância, uma atividade de construção de modelos. Um modelo é uma representação de alguma coisa do mundo real, uma abstração da realidade, ou seja, representa uma seleção de características do mundo real, que são relevantes para o propósito com o qual o modelo foi construído. Tipos de análise de sistema Os tipos de análise de desenvolvimento de sistema (método) se diferenciam pela maneira como o problema deve ser visualizado e como a solução do problema deve ser modelada, esses métodos podem ser dados: » Decomposição de funções: que envolve a análise estruturada caracterizada pela decomposição das funções por meio do Diagrama de Fluxo de Dados (DFD) e de Modelo Hierárquico de Tarefas (MHT). » Estrutura de dados: que aborda a decomposição de um problema a partir dos dados através do Diagrama Entidade-Relacionamento (DER). » Orientação a objeto: essa abordagem é constituída na decomposição do problema a partir dos objetos pertencentes a um domínio e representada pela UML (Unified Modeling Language – Linguagem de Modelagem Unificada). Análise estruturada Os métodos de desenvolvimento de sistema se diferenciam pela maneira como o problema deve ser visualizado e como a solução do problema deve ser modelada. A análise estruturada ou SSA (Structured System Analysis) foi desenvolvida em meados dos anos 70 por Gane, Sarson e De Marco. Esse método é baseado na utilização de uma linguagem gráfica para construir modelos de um sistema, incorporando conceitos relacionados às estruturas de dados. Os elementos básicos da Análise Estruturada são: ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS | UNIDADE II » Diagrama de fluxo de dados (DFD): é uma técnica gráfica de representação que permite realizar uma decomposição hierárquica de processos (abordagem top-down – decompondo o nível mais elevado, menos detalhado, para os níveis subordinados menores mais detalhados – o inverso disso é chamado de abordagem bottom-up), explicitando os fluxos de entrada informação e as transformações que são aplicadas à medida que os dados se deslocam em direção à saída. Um DFD assume o formato de um esquema como o ilustrado na Figura 13. Figura 13 – Diagrama DFD Nota: O objetivo principal de um DFD é expressar quais as transformações são aplicadas aos dados, sem preocupação em representar como são processadas estas transformações. » Dicionário de dados: que fornece a informação de texto de suporte para complementar a informação gráfica mostrada no DFD, é simplesmente um grupo organizado de definições de todos os elementos de dados no sistema sendo modelado. O dicionário de dados contempla todos os diagramas da análise estruturada, conforme Yourdon (1990). UNIDADE II ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS Quadro 5 — Dicionário de dados DFD — Notação de Youdon Símbolo | Significado = | É composto de + | E [] | Escolha uma das opções alternativas {} | Interações de () | Opcional (pode estar presente ou ausente) [] | Separa as opções alternativas na construção ** | Comentário <> | Identificador (campo chave) de um depósito de dados Fonte: Adaptado do trabalho Engenharia de Software - Valterio M. Pereira Jr. » Diagrama de entidade-relacionamento (DER): Também conhecido como modelo de dados (MER). Ele enfatiza os principais objetos, ou entidades com o que o sistema lida, bem como a relação entre os objetos. Os objetos normalmente correspondem, um a um, aos locais de armazenagem de dados mostrados no DFD, mas o DFD não informa sobre as relações entre os objetos. Mostra uma visão estática das informações (entidades) de interesse e dos vínculos (relacionamentos) existentes entre elas (Figura 14). Figura 14 — Diagrama DER/MER Figura adaptada do site: <http://www.odairas.xpg.com.br/atividade1/documentoshtml/bdodairM.html> A análise estruturada possui algumas limitações, Snyder (1993), coloca que um sistema desenvolvido usando um método estruturado, frequentemente, é difícil de ser mantido. A princípio, o problema principal tem origem pelo fato de que todas as funções devem ser conhecidas e como os dados serão armazenados, isto é, a estrutura dos dados. Diferentes programas podem dar diferentes interpretações aos dados e, portanto, é necessário conhecer como eles foram projetados para poder interpretá-los corretamente. Para Pompilho (1995), a abordagem top-down, embora esta seja uma boa maneira de se atacar um problema complexo — começando da visão geral e ir descendo, passo a passo, numa visão hierárquica, há níveis de detalhes cada vez maiores — na prática, esta abordagem não se mostrou eficiente como estratégia de projeto para a decomposição de sistemas. ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS | UNIDADE II Análise essencial Segundo Xavier (1995), a análise essencial de sistemas, por meio da técnica de partionamento (divisão) por eventos, oferece uma boa estratégia para modelar o comportamento do sistema, visando satisfazer os requisitos do usuário, partindo do princípio que dispomos de uma tecnologia perfeita e que ela pode ser obtida a custo zero. Apesar de introduzir novos conceitos e novas abordagens, esse método reservou todos os modelos da análise estruturada, com a adição do diagrama de estado (DTE). Esse diagrama é usado para modelar o comportamento de transição de estado, é uma ferramenta de modelagem para descrever o comportamento do sistema. Cada estado representa o período de tempo durante o qual o software tem algum comportamento desejável; as setas conectando cada quadro retangular mostra a mudança de estado, ou transições de um lado a outro (Figura 15). Associadas a cada mudança de estado estão uma ou mais condições (os eventos ou circunstâncias que causam a mudança de estado), e zero ou mais ações (a resposta, ou saída, advindo que ocorre para parte da mudança de estado). Figura 15 – Diagrama DTE Eleitor Apresenta cartão de eleitor Em Votação Devolve boletins de voto Votante Confirmado Devolução do cartão de eleitor Mudança de morada ou morte Eliminado Devolução do cartão de eleitor Figura adaptada do site: <http://www.odairas.xpg.com.br/atividade1/documentoshtml/bdodair.html> A melhor maneira de encarar a análise essencial é considerá-la como uma evolução da análise estruturada. A Figura 16 mostra a arquitetura básica desse paradigma. UNIDADE II ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS Figura 16 – Diagrama DER Análise Essencial Modelo Essencial Modelo de Implementação Modelo Ambiental Modelo Comportamental Figura adaptada do site: <http://pt.wikipedia.org/wiki/An%C3%A1lise_essencial> » Modelo essencial: representa o sistema num grau de abstração completamente independente de restrições tecnológicas. » Modelo de implementação: passa a considerar as restrições tecnológicas impostas pela plataforma de hardware e software a ser utilizada para implementar o sistema. Na realidade, a principal diferença entre a Análise Essencial e a Análise Estruturada está na estratégia para atacar o problema: a primeira defende uma abordagem baseada em eventos, em que a análise de eventos passa a ser um passo fundamental, a segunda é baseada apenas na decomposição top-down das funcionalidades do sistema (Figura 17). Figura 17 – Diagrama DER Modelo Essencial Modelo Ambiental Modelo Comportamental Lista de Eventos Diagrama de Contexto Declaração de Objetivos Diagrama de Fluxo de Dados Diagrama de Entidades e Relacionamentos Mini-Especificações DICIONÁRIO DE DADOS Diagrama de Transições de Estados Figura adaptada do trabalho Introdução à Análise Essencial - Prof. Ricardo de Almeida Falbo ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS UNIDADE II Para Pomplho (1995) a Análise Essencial propõe outra forma de particionamento, a qual é baseada nos eventos, e que tem demonstrado ser mais efetiva do que a abordagem top-down da análise estruturada, pois torna mais fácil a identificação das funções e entidades que compõem o sistema. Análise orientada a objetos Segundo Sommerville (2007), a Análise Orientada a Objetos (AOO) concentra-se no desenvolvimento de um modelo orientado a objetos do domínio da aplicação. Os objetos nesse paradigma (modelo) refletem as entidades (classes), seus atributos (características) e as operações (métodos) associadas ao problema a ser resolvido, e sim dividida um dos padrões mais utilizados atualmente. Para Pressman (2006) em vez de examinarmos o problema usando um modelo convencional com entrada-processamento-saída ou um modelo derivado de estruturas hierárquicas (Modelo Estrutural ou Estrutural), a AOO cria um modelo orientado a classes, que se apoia no entendimento das estruturas do OO (Orientação a Objetos). Conceitos fundamentais de OO A OO refere um número de conceitos bastante apropriados para a modelagem de sistemas. Tais modelos são baseados em objetos e o que facilita: a compreensão de problemas, a comunicação com os usuários e os usuários e para a realização das tarefas ao longo do processo de desenvolvimento e análise. Os conceitos importantes em AOO conforme Silva e Vieira (2001) são: Abstração: Ação de coletar apenas as características e comportamentos importantes a respeito de um objeto para atingir um objetivo. Note que na Figura 18, o ponto de vista a respeito de um objeto observado (gato), varia conforme o que se considera importante do ponto de vista do observador. Figura 18 – Características e comportamentos essenciais Figura adaptada do livro AOO e design c/ Aplicações – Booch (1994) Nota: As abordagens tradicionais concretizam esta ideia pelas abstrações funcionais (processos), enquanto os métodos orientados por objetos utilizam objetos. 45 UNIDADE II ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS Encapsulamento: encapsulamento da informação é o processo de “ocultar” todos os detalhes de um objeto que não contribuem para as suas características essenciais nem para a as suas funcionalidades externas. Esta característica permite a criação de objetos estáveis e reutilizáveis, reproduzindo o mundo real de forma correta (Figura 19). Figura 19 – Conceito de Encapsulamento Figura adaptada do livro AOO e design c/ Aplicações – Booch (1994) Herança: representa a definição de relações entre classes por meio da qual uma subclass (classe filha) partilha, acrescenta ou redefine operações (métodos) e atributos (características) a partir de uma ou mais superclasses (ou classe mãe/pai). Uma subclasse é uma especialização de uma classe mais genérica (superclasse – Figura 20). Figura 20 – Conceito de Encapsulamento Figura adaptada do livro AOO e design c/ Aplicações – Booch (1994) Polimorfismo: uma forma de definir esta propriedade é dizer que ela representa a capacidade de diferentes objetos responderem de forma diferente à mesma mensagem. Mais utilizada em situações em que uma operação é compartilhada de uma superclasse para uma subclasse, mas, modificando a sua forma para uma versão mais específica, que atenda o contexto para resolver o problema. 46 ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS Objeto: Para Booch (1994) é algo ao qual se pode fazer qualquer coisa; tem estado, comportamento e identidade (ser único). Corroborando com esse conceito, Rumbaugh (1991) afirma que um objeto é um conceito, abstração ou coisa com fronteiras (limites) bem definidas e com significado para o problema em questão. Vale lembrar que o estado de um objeto é definido pelo valor de seus atributos e seu comportamento definido pelo conjunto de ações (métodos ou operações) que esse objeto pode realizar de forma independente (Figura 21). Figura 21 – Conceito de Objeto estado comportamento identidade Figura adaptada do livro AOO e design c/ Aplicações – Booch (1994) Atributos: são características nomeadas de um objeto que indicam os valores possíveis que esse atributo pode assumir ao longo do tempo, por exemplo, pensando um objeto veículo, poderíamos obter alguns atributos como: tipo de veículo, número de rodas, velocidade, consumo de combustível e outros, sempre lembrando que esses atributos são identificados com base em uma necessidade específica. Identidade: Segundo Rumbaugh (1994), no mundo real um objeto limita-se a existir, mas, no que se refere ao mundo computacional, cada objeto dispõe de um identificador único pelo qual pode ser referenciado, como por exemplo, podemos identificar um veículo do tipo carro por meio de seu atributo placa. Classes: Booch (1994) afirma que as classes representam um conjunto de objetos que compartilham as mesmas características (atributos) e comportamentos (métodos ou operações) e que um único objeto é apenas uma instância da classe. Para Silva e Vieira (2001) uma classe pode ser vista como um modelo para um determinado objeto e todos os que lhe forem semelhantes, assim como uma fábrica, que produz tantos objetos idênticos quanto necessário (Figura 22). 47 UNIDADE II | ENGENHARIA DE REQUISITOS E ANÁLISES ESSENCIAIS Figura 22 – Conceito de Classe Figura adaptada do livro AOO e design de Aplicações - Booch (1994) • Mensagens: As mensagens são o meio de comunicação entre objetos e são responsáveis pela ativação de todo e qualquer tipo de processamento. Dessa forma, é possível garantir que clientes não serão afetados por alterações nas implementações de um objeto que não altere o comportamento esperado de seus serviços. Para Jacobson (1992), AOO é uma maneira mais natural para descrever sistemas, já que os objetos são geralmente bastante estáveis. Alterações que por ventura venham a ocorrer, geralmente, afetam um ou apenas alguns poucos objetos. Dessa maneira, o paradigma orientado a objetos utiliza uma perspectiva mais humana de observação da realidade e seus benefícios esperados com o uso desse padrão são: • Capacidade de enfrentar novos domínios de aplicação. • Melhoria da interação entre analistas e especialistas. • Aumento da consistência interna dos resultados da análise. • Uso de uma representação básica consistente para a análise e projeto. • Alterabilidade, legibilidade e extensibilidade. • Possibilidade de ciclos de desenvolvimento variados. • Apoio à reutilização quer seja de modelos ou até mesmo de código. 48