Aula desesenvolvimento segunda semana

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


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


• 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 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


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




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




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


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



•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”



•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


Quando o “todo” morre todas as suas “partes” também morrem


Elementos de um diagrama de classes :Classes Relacionamentos Associação • Agregação • Composição Generalização Dependência


•Relacionamento: Generalização É um relacionamento entre itens gerais

(superclasses) e itens mais específicos (subclasses)




•Relacionamento: Dependência Representa que a alteração de um

objeto (o objeto indepedendente) pode afetar outro objeto (o objeto dependente)


Obs: o A classe cliente depende de algum

serviço da classe fornecedoro A mudança de estado do fornecedor afeta

o objeto cliente

Education

Aula desesenvolvimento segunda semana