aula desesenvolvimento segunda semana
TRANSCRIPT
Conhecendo as técnicas do estudo de análise
Profª Taliane Lima
Os paradigmas de desenvolvimento de sistemas
Primeiros sistemas – até 70
• Aplicações não tinham grandes dimensões • Limitações das máquinas existentes • Análise sem métodos e formalismos • Praticamente a ferramenta era o fluxograma • Derivação da fase de análise para fase de
projeto sem critérios
Os paradigmas de desenvolvimento de sistemas
Mais tarde – década de 70
• Conceito de Engenharia de Software surge em repulsa à crise de informática – 1968
• Dijkstra escreve sobre a programação
estruturada dando importância à complexidade dos sistemas.
• Codd descreve o modelo Relacional para
banco de dados – 1978
• Niklaus Wirth desenvolve o Pascal
Os paradigmas de desenvolvimento de sistemas
• A linguagem C e desenvolvida por Ritchie
• A análise estruturada é popularizada por Tom Demarco
• Passamos a conviver com Diagramas de Fluxo de Dados (DFD), Diagramas de Entidades e Relacionamento (DER) e outros naquilo que ficou conhecido como Análise Essencial
Porém...
•Existia uma dificuldade em garantir a compatibilidade entre as fases de análise e projeto e desta para a de implementação. Alteração ou extensões dos modelos criados necessitam de grande esforço.
•A comunicação entre desenvolvedores e usuários era difícil, os modelos fugiam à compreensão dos usuários.
O início de novo paradigma
• Ainda na década de 70, métodos orientados a objetos começaram a surgir amadurecendo nova mudança de paradigma com o conceito de análise orientada a objetos.
• E mais, melhorou a comunicação entre desenvolvedores e usuários, com estes conseguindo participar mais ativamente do desenvolvimento, pela análise e validação dos diagramas apresentados.
• Na tentativa de reverter à crise foram propostas metodologias de desenvolvimento de sistema:
Análise Estruturada ( processos e dados);
Análise Essencial (processos, dados e controle);
Análise Orientada a Objetos (paradigma de objeto);
Análise Estruturada•A analise estruturada consiste na
construção de um modelo lógico de sistemas, utilizando técnicas gráficas capazes de levar usuários, analistas e projetistas a formarem um quadro claro e geral do sistema e de como suas partes se encaixam para atender às necessidades daqueles que dele precisam.
Análise Essencial•A Análise Essencial de Sistemas pode ser
considerada uma evolução da análise estruturada, propondo o reparticionamento do sistema, utiliza-se das mesmas ferramentas de modelagem da análise estruturada, mas com mecanismos diferentes.
OS MÉTODOS...Análise Estruturada Análise Essencial
Diagrama de Fluxo de Dados(DFD)
Diagrama de Estrutura de Dados) Modelo Conceitual
Miniespecificações Normalização Dicionário de Dados
Diagrama de Fluxo de Dados(DFD)
Lista de Eventos Diagrama de Entidade –
Relacionamento(DER) Diagrama de Transição de
Estado(DTE) Miniespecificações Normalização Dicionário de Dados
Linguagens tradicionais
Análise Orientada a Objetos• A Análise Orientada a Objetos parte do paradigma de que o mundo é formado de objetos e de que desenvolver um sistema nada mais é que criar uma simulação dos objetos e de seu comportamento.
OO•A orientação a objetos propicia aumento
de produtividade, menor custos de desenvolvimento e de manutenção e, ainda, maior portabilidade e reutilização de código.
•Classes – de onde se originam os objetos – bem escritas reduzem tempo e custo de desenvolvimento.
•MER OOA
Entidade ------------------> Classe
Ocorrência ----------------> Objeto
Atributo -------------------> Atributo
EXEMPLO:
Sistema de cadastramento de veículos
O COMEÇO...1. A crise do software aconteceu em meados da
década de 1970.2. Causadas pelo aumento da demanda e da
necessidade de uso de softwares.3. Essa crise foi desencadeada a partir de um
conjunto de problemas como: muitas descrições textuais de difícil
compreensão e manutenção ocorrendo ambiguidades prazos e custos extrapolados dificuldades envolvendo a construção
implantação e manutenção dos softwares.
•Os estudos sobre a tecnologia de objetos iniciaram-se na década de 1980 com ênfase nas linguagens de programação. No final da mesma década começaram a surgir os métodos de análise e projeto. Os principais métodos foram de:
• SHLAER & MELLOR (1989 e 1991);• COAD & YOURDON (1991);• COAD & NICOLA (1993);• COAD et al. (1995);• WIRFS-BROCK et al. (1990);• BOOCH (1994 e 1995);• RUMBAUGH et al. (1991 e 1996);• MARTIN & ODELL (1994 e 1995);• JACOBSON (1994 e 1995).
•Guerra dos métodos.•Durante 1996 eles trabalharam no
método que passou a chamar de Unified Modeling Language (UML)
•Object Management Group (OMG) iniciou um esforço para padronização na área de métodos.
UML – A Linguagem de Modelagem Unificada •“A UML proporciona uma forma padrão
para a preparação de planos de arquitetura de projetos de sistemas, incluindo aspectos conceituais tais como processos de negócios e funções do sistema, além de itens concretos como as classes escritas em determinada linguagem de programação, esquemas de bancos de dados e componentes de software reutilizáveis”
UML – A Linguagem de Modelagem Unificada
•Os elementos gráficos têm sintaxe – forma predeterminada – evitando ambiguidades. Com isto evita que um analista modele uma classe como um retângulo e outro como um cubo. Elementos também possuem semântica – significado e função.
Diagramas da UML
Diagramas de Casos de Uso (Use Case)
•É um diagrama usado para se identificar como o sistema se comporta em várias situações que podem ocorrer durante sua operação.
•Ator: Representa qualquer entidade que interage com o sistema durante sua execução essa interação se dá através de comunicações (troca de mensagens).
•Um ator pode ser uma pessoa (usuário, secretaria, aluno...), um dispositivo (impressora, máquina...), hardware (placa de modem, scaner...), softwares (sistema de bd, aplicativos...), etc.
Algumas de suas características são descritas abaixo:
Ator não é parte do sistema. Representa os papéis que o usuário do sistema pode desempenhar. Ator pode interagir ativamente com o sistema. Ator pode ser um receptor passivo de informação. Ator pode representar um ser humano, uma máquina ou outro sistema.
Representação:
•Como foi exemplificado acima, é uma sequencia de ações que o sistema executa e produz um resultado de valor para o ator. Modela o dialogo entre os atores e o sistema; é um fluxo de eventos completos.
Algumas de suas características são descritas abaixo:Um "Use Case" modela o diálogo entre atores e o sistema.Um "Use Case" é iniciado por um ator para invocar uma certa funcionalidade do sistema.Um "Use Case" é fluxo de eventos completo e consistente.O conjunto de todos os "Use Case" representa todas as situações possíveis de utilização do sistema.
•Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos:
•Os relacionamentos em um diagrama de casos de uso podem envolver dois atores e dois casos de uso ou um ator e um caso de uso e assim sucessivamente. O relacionamento é representado através de uma seta :
EXEMPLO DE CASO DE USOSistema automatizado de Matrícula num Curso
•Um Caso de Uso é uma fatia de funcionalidade do sistema, sem superposição nem lacunas, que representam algo de valor para os usuários finais.
•Um Ator é representação dos usuários e outros sistemas que interagem com o produto
•Os Diagramas de Caso de Uso exibe os relacionamentos entre atores e casos de uso, deixando claro que grupos utilizam quais
funções.
Diagrama de Casos de Uso
•Esse diagrama documenta o que o sistema faz do ponto de vista do usuário. Em outras palavras, ele descreve as principais funcionalidades do sistema e a interação dessas funcionalidades com os usuários do mesmo sistema.
•Nesse diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema faz.
EXERCITANDO...Desenvolver um diagrama de caso de uso, de acordo com as características abaixo:1)Certa agência, possui um atendente onde este é responsável pelo abastecimento de dinheiro ao caixa eletrônico.2)Nesta mesma agência um cliente verifica o saldo da conta3)O cliente solicita extrato4)O cliente realiza saque5)O cliente realiza deposito6)O atendente recolhe o envelope de depósito do cliente
Análise
O fluxo da Análise tem como objetivos:• modelar de forma precisa os conceitos
relevantes do domínio do problema, identificados a partir do levantamento de requisitos;
• verificar a qualidade dos requisitos identificados;
• detalhar esses requisitos o suficiente para que atinjam o nível de detalhe adequado aos desenvolvedores.
•Quando se usa um Modelo de Análise orientado a objetos, os requisitos funcionais são tipicamente descritos e verificados através dos seguintes recursos de notação:
• Os casos de uso descrevem o comportamento esperado do produto.
• Os diagramas de casos de uso descrevem os relacionamentos dos casos de uso entre si e com os atores.
• As classes representam os conceitos do mundo da aplicação que sejam relevantes para a descrição mais precisa dos requisitos, exibindo os relacionamentos entre essas.
• As realizações dos casos de uso mostram como objetos das classes descritas colaboram entre si para realizar os principais roteiros que podem ser percorridos dentro de cada caso de uso.
UML – Diagrama de Classes
• Introdução – Diagrama de classes• Elementos do diagrama de classes• Exemplo: Sistema de matrícula
Introdução - Diagrama de Classes
• Mostra um conjunto de classes e seus relacionamentos.
• É o diagrama central da modelagem orientada a objetos.
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes Relacionamentos Associação •Agregação • Composição Generalização Dependência
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes RelacionamentosAssociação •Agregação • Composição Generalização Dependência
Elementos – Diagrama de ClassesClasses• Graficamente, as classes são
representadas por retângulos incluindo nome, atributos e métodos.
• Devem receber nomes de acordo com o vocabulário do domínio do problema.
• É comum adotar um padrão para nomeá-las
Ex: todos os nomes de classes serão substantivos singulares com a primeira letra maiúscula
Elementos – Diagrama de ClassesClasses Atributos Representam o conjunto de
características (estado) dos objetos daquela classe
Visibilidade: + público: visível em qualquer classe de
qualquer pacote # protegido: visível para classes do
mesmo pacote - privado: visível somente para classe
Exemplo: + nome : String
Elementos – Diagrama de Classes
ClassesMétodos – Representam o conjunto de operações
(comportamento) que a classe fornece Visibilidade:+ público: visível em qualquer classe de
qualquer pacote# protegido: visível para classes do mesmo
pacote- privado: visível somente para classe
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes Relacionamentos Associação •Agregação • Composição Generalização Dependência
Elementos – Diagrama de Classes
Relacionamentos•Os relacionamentos possuem:– Nome: descrição dada ao
relacionamento (faz, tem, possui,...)– Sentido de leitura– Navegabilidade: indicada por uma seta
no fim do relacionamento
– Multiplicidade: 0..1, 0..*, 1, 1..*, 2, 3..7– Tipo: associação (agregação, composição), generalização e dependência– Papéis: desempenhados por classes em um relacionamento
Relacionamentos
Relacionamentos
•O cliente sabe quais são seus endereços, mas o endereço não sabe a quais clientes pertence
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes Relacionamentos Associação •Agregação • Composição Generalização Dependência
Elementos – Diagrama de Classes
Relacionamentos: - Associação Uma associação é um relacionamento
estrutural que indica que os objetos de uma classe estão vinculados a objetos de outra classe.
Uma associação é representada por uma linha sólida conectando duas classes.
Associação
Elementos – Diagrama de Classes
Relacionamentos: Associação Indicadores de multiplicidade: – 1 Exatamente um – 1..* Um ou mais– 0..* Zero ou mais (muitos) – * Zero ou mais (muitos) – 0..1 Zero ou um – m..n Faixa de valores (por exemplo: 4..7)
•Relacionamentos: AssociaçãoExemplo:Um Estudante pode ser um aluno de
uma Disciplina eum jogador da Equipe de Futebol
• Cada Disciplina deve ser cursada por no mínimo 1 aluno
• Um aluno pode cursar de 0 até 8 disciplinas
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes Relacionamentos Associação •Agregação • Composição Generalização Dependência
•Relacionamento: Agregação
– É um tipo especial de associação – Utilizada para indicar “todo-parte”
– um objeto “parte” pode fazer parte de vários objetos “todo”
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes Relacionamentos Associação •Agregação • Composição Generalização Dependência
•Relacionamento: Composição
– É uma variante semanticamente mais “forte” da agregação
– Os objetos “parte” só podem pertencer a um único objeto “todo” e têm o seu tempo de vida coincidente com o dele
Elementos – Diagrama de Classes
Quando o “todo” morre todas as suas “partes” também morrem
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes Relacionamentos Associação • Agregação • Composição Generalização Dependência
Elementos – Diagrama de Classes
•Relacionamento: Generalização É um relacionamento entre itens gerais
(superclasses) e itens mais específicos (subclasses)
Elementos – Diagrama de Classes
Elementos de um diagrama de classes :Classes Relacionamentos Associação •Agregação • Composição Generalização Dependência
Elementos – Diagrama de Classes
•Relacionamento: Dependência Representa que a alteração de um
objeto (o objeto indepedendente) pode afetar outro objeto (o objeto dependente)
Elementos – Diagrama de Classes
Obs: o A classe cliente depende de algum
serviço da classe fornecedoro A mudança de estado do fornecedor afeta
o objeto cliente