ADS
- 28/02/2013
Análise de Sistemas
Determina e específica o
que i sistema deve fazer.
Diagrama e Documentação
No contexto de
desenvolvimento de software correspondem a desenhos gráficos que seguem algum
padrão lógico;
Podemos também dizer que
um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem
um significado predefiido;
Diagramas normalmente
são construídos de acordo com regras de notação bem definidas;
Modelagem de Sistemas de Software
A abstração do sistema
de software através de modelos que o descrevem, é um poderoso instrumento para
o entendimento e comunicação do produto final que será desenvolvido.
Um modelo pode ser visto
como uma representação idealizada de um sistem a ser construído;
Maquetes de edificios e
de aviões e plantas de circuitos eletronicos são apenas alguns exemplos de
modelos;
Uma simplificaçao de
realidade que nos ajuda a entender um problema complexo.
Fases de Desenvolvimento de Sistemas
1 - Concepção
2 - Transição
3 - Elaboração
4 - Construção
Levantamento de Requisitos
Um requisito é definido
como "uma condição ou uma capacidade com qual o sistema deve estar de
acordo".
Requisitos Funcionais
Os requisitos funcionais
especificam ações que um sistema deve ser capaz de executar, sem levar em
consideração restrições físicas. Geralmente, isso é melhor descrito em um modeo
de casos de uso. Os requisitos funcionais especificam, portanto, o corpotaento
de entrada e saída de um sistema.
OBS: Restrições físicas
Requisitos não Funcionais
Requisitos
não-funcionais descrevem qualidades do sistema (como sistema é) ao invés de
suas funcionalidades (o que ele faz).
USABILIDADE - Resista a
solicitações como "O software deve ser amigável para o usuário". Isso
não é suficiente.
PERFORMANCE - "Todo
o sistema deve ter a melhor perfomance possível".
ADS
- 07/03/2013
Diagrama de Fluxo de Dados
O DFD é uma ferramenta
para modelagem de sistemas. Ela fornece apenas uma visão do sistema, a visão
estruturada das funções, ou seja, o fluxo dos dados.
Diagrama de Contexto
É conhecido como DFD de
Nível 0, recebe esse nome por conta da pouca profundidade de análise.
Entidades
São categorias lógicas
de objetos ou pessoas que representam Origem ou destino de dados, e, que
acionam um sistema e/ou recebem informações;
Podem ser pessoas,
sistemas ou unidades departamentais;
REGRAS:
1 - X-Letra para
identificação;
2 - Nome - Nome da
Entidade: Ex: Clientes, Sistema Acesso, Banco, etc
Fluxo
de Dados
São o meio por onde os
dados e as informações trafegam;
REGRAS:
Nome: Nome do dado. Ex:
Pedido, Nota Fiscal, Produto, Item.
Argumentos: Argumento de
Acesso a um depósito. Ex: CFC, CPF, CEP, Código, Matricula, Nome, Etc...
Sempre Envolvem
processos não sendo possivel o fluxo de entidades para entidades, entidade para
deposito de dados, depósito de daos para depósito de dados.
PROCESSOS
Transformam fluxos de
dados em uma atividade;
Normalmente os módulos
do sistema.
REGRAS:
·
N:
Número de referência do processo Ex: 0, 1, 2, 3,, 1.1, 1.2
·
FUNÇÃO:
Descreve o processo no verbo infinitivo. Ex: Cadastrar Cliente, gerar arquivo,
Imprimir Relatório, etc.
·
LOC:
Loal físico onde se desenvolve o processo. Ex: Almoxarifado , Contabilidade,
etc.
·
DICA:
Para descobrir um processo relate os requisitos do sistema. (Cadastrar
Clientes, Efetuar Logon, Etc.)
DEPÓSITO
DE DADOS
São locais de
armazenamento de dados
São arquivos físicos
REGRAS:
DN: Número do depósito.
Ex: 0,1,2,3, D1/1, D1/2
Nome: nome do deposito.
Ex: Clientes, Produtos, Contas, etc.
Para tornar mais fácil
identificar DD leve em conta dois tipos de arquivos: Cadastral e de Movimento
(Movimentod de Itens, etc.)
ADS
- 22/03/2013
·
Modelagem
de sistema
·
Modelos
de analise
·
Processo
em cascata
·
Prototipagem
·
Processo
unificado
·
Requisitos
·
Tipos
de requisitos
MODELAGEM
DE SISTEMAS DE SOFTWARE
A abstração do sistema de um software através
de modelos que o descrevem é um poderoso instrumento para o entendimento e
comunicação do produto final que será desenvolvido.
MODELOS DE ANALISE
·
MODELO
DE NEGOCIO: descrevem como funciona o negocio onde o sistema esta inserido.
·
MODELO
FUNCIONAL: Descreve a funcionalidade essencial do sistema, utilizando diagramas
de fluxo de dados.
·
MODELO
DE DADOS: Descreve os dados guardados pela memória do sistema na forma de um
modelo conceitual e segundo o método de entidades e relacionamentos.
PROCESSO EM CASCATA
Também conhecido como
linear seqüencial. Nesse processo assumimos que as ativadades de analise,
projeto e implementação podem ser feitos de forma seqüencial, sem que sejam
necessárias interações entre as fases.
·
MODELAGEM>
ANALISE DE REQUISITOS> PROJETO> CODIFICAÇÃO> TESTES> MANUTENÇÃO
·
MODELAGEM
DO SISTEMA: onde são estabelecidos os requisitos do sistema do qual o software
sendo realizado participa, incluindo os requisitos de informações e de negócios.
·
ANALISE
DE REQUISITOS: Onde são modelado os
requisitos de informações, funcionais, comportamentais, de desenpenho e de
interface do softaware.
Prototipagem
O desenvolvedor interage
diretamente com o usuário, escutando seus pedidos e desenvolvendo,
imediatamente, um protótipo do produto desejado. O usuário, então, utiliza esse
protótipo e fornece ao desenvolvedor novas informações que o levam a modificar
o protótipo, de maneira a atender todas as necessidades do usuário.
Detalhamento
1.Concepção - fase em que se enfatiza o processo de
análise de negócios e análise de requisitos do negócio analisado, dando uma
ênfase menor a arquitetura e implementação;
2.Elaboração - fase em que se enfatiza o processo
de desenvolvimento da análise arquitetural da solução proposta;
3.Construção - fase em que se enfatiza o processo
de implementação da solução proposta, bem como, testes e integração;
4.Transição - fase em que se enfatiza o processo
de implantação do release, com importante foco na realização do teste beta e
reconfiguração necessária do sistema, além de foco no processo de treinamento
do usuário e conversão dos dados legados.
Requisitos
·
É
o estudo das características que o sistema deverá ter para atender às
necessidades e expectativas do cliente.
·
Um
requisito é definido como "uma condição ou uma capacidade com a qual o
sistema deve estar de acordo".
Tipos de Requisitos
·
Requisitos
funcionais: Os
requisitos funcionais especificam ações que um sistema deve ser capaz de
executar, sem levar em consideração restrições físicas. Geralmente, isso é
melhor descrito em um modelo de casos de uso e em casos de uso. Os requisitos
funcionais especificam, portanto, o comportamento de entrada e saída de um
sistema.
·
Requisitos
não-funcionais
descrevem qualidades do sistema (como o sistema é) ao invés de suas
funcionalidades (o que ele faz).
·
Usabilidade: resista a solicitações como “O
software deve ser amigável para o usuário”. Isso não é suficiente.
·
Performance:
“Todo o sistema deve
ter a melhor performance possível”.
ADS
– 04/04/2013
Ponto chave do modelo:
Entidades podem se
relacionar, o que relamente da o sentido ao nome do modelo
O objeto do modelo ER
nada mais é do que possibilitar a navegação entre o fluxo.
ENTIDADE
RELACIONAMENTO
LIGAÇÃO
ENTRE ENTIDADE
·
Entidades-
as entidades são objetos relevantes para a aplicação, que apresentam
características próprias. É o objeto concreto ou abstrato onde serão
armazenadas as informações necessárias para amparar o projeto em
desenvolvimento.
·
Atributos-
Os atributos são classes de valores que representam as propriedades elementares
das entidades. È a menor parcela de informações dentro de uma entidade
apresentando um significado próprio.
·
São
associações (conexão) entre entidades da
aplicação, que representam um fato ou situação do mundo real. A identificação do relacionamento entre as
entidades é amplamente facilitada pela verificação da existência de atributos
comuns nas entidades.
·
1:1
( UM-PARA-UM)
·
1:N
( UM-PARA-MUITOS)
·
M:N
(MUITOS-PARA-MUITOS)
1:1- neste
relacionamento, cada um dos elementos de uma entidade só pode se relacionar com
apenas um elemento de outro, entidade.
Então, consideremos as
tabelas clientes e documentos em que cada um dos clientes pode ter apenas um
documento ( considerando que nesta tabela um mesmo cliente não pode ter mais de
um documento) assim como cada um dos documentos só pode pertencer a um cliente.
1:N- neste
relacionamento que é um dos mais comuns hoje em dia cada elemento da entidade
“A“ pode ter um relacionamento com vários elementos da entidade”B” . Em
contrapartida cada um dos elementos da entidade B pode estar relacionado a
apenas um elemento da A.
Então consideremos a
tabela clientes já criadas e agora vamos creiar a tabela telefones, já que neste
caso cada Cliente pode ter varios Telefones mais cada telefone pode pertencer a
um somente um cliente.
N:N- Nestes
relacionamentos, que é diferentes dos outros, os dados então diretamente
relacionados aos fatos, e não as entidades, como os outros dois anteriores.
Seguindo as regras deste tipo de relacionamento, temos que ibrigatoriamente,
criar três tablas, já que a terceira tem
a responsabilidade crucial de fazer o relacionamento entre as outras duas.
Para um melhor
compreensão vamos usar novamente a tabela, clientes e a tabela Pedidos, criada
no artigo anterior . Com elas temos a seguinte situação: um cliente pode fazer
diversos pedidos ao passo que um pedido pode ser feito por diversos clientes.
Uma limitação do modelo
E-R é que não é possível expressar relacionamentos entre relacionamentos.
Agregação é uma
abstração através da qual relacionamentos são tratados como:
Generalização
e Especialização
Existem casos em que o
conjunto – entidade pode ser dividido em categorias cada qual com atributos
específicos
Generalização
/ especificação não-exclusiva
Herança múltipla
Dependência existencial
Ocorre quando a
existência de uma determinada entidade esta condicionada a existência de uma
outra entidade a ela relacionada.
----------------------------------------------------------------------------------------------------------
ENTIDADE - REPRESENTA UM
OBJETO COM IDENTIFICAÇÃO UNICA EM RELAÇÃO AOS OUTROS OBJETOS.
ATRIBUTO - REPRESENTA AS
CARACTERISTICAS DE UM OBJETO.
RELACIONAMENTO -
REPRESENTA A FORMA COM QUE AS ENTIDADES(OBJETOS) SE RELACIONAM.
TIPOS DE RELACIONAMENTO
RELACIONAMENTO 1-1: UMA
ENTIDADE DE "A" SE RELACIONA COM UMA ENTIDADE DE "B".
RELACIONAMENTO 1-N: UMA
ENTIDADE DE "A" SE RELACIONA COM VARIAS ENTIDADES DE "B".
RELACIONAMENTO N-N OU
N-M: VARIAS ENTIDADE DE "A" SE RELACIONAM COM VARIAS ENTIDADES DE
"B".
CARDINALIDADE -
REPRESENTA A CAPACIDADE COM QUE AS ENTIDADES SE RELACIONAM ENTRE SI, OU SEJA:
ENTIDADE 1 -
DEPARTAMENTO
ENTIDADE 2 - EMPREGADOS
ONDE 1 DEPARTAMENTO
POSSUI VÁRIOS EMPREGADOS.
ONDE 1 EMPREGADO ATUA EM
1 DEPARTAMENTO.
----------------------------------------------------------------------------------------------------------------
ADS – 11/04/13
POO
Uma abordagem tipica
usada no desenvolvimento de programas, complexos consiste em decompor os
programas e diversos módulos e dividir cada modulo em diversas funções. Cada
função é responsável por parte da solução do problema. Esta abordagem de desenvolvimento se baseia na decomposição
funcional. Embora a decomposição funcional tenha sido amplamente utilizada nos
utimos anos, apresenta algumas defieciencias tais como o fraco acoplamento
entre dados e funções.
A orientação a objetos,
também conhecidas como programação orietada a objetos(POO) ou ainda em ingles
object-oriented Programming (OOP) é um paradigma de analise projeto e
programação de sistemas de baseado na
composição e interação entre diversas unidades de software chamados de objetos.
Em outras palavras, os softwares são compostos por módulos (objetos) cujos
dados e funções são fortemente acopladas.
Conceitos bases
Os principais conceitos
de orientação a objetos são: classes, objetos, estado, comportamento,
encapsulamento, mensagens e abstração;
Classe
Em orientação a objeto
uma classe é um estrutura que abstrai um conjunto de objetos com
características similares. Uma classe define o comportamento de seus objetos
através de métodos e os estados possíveis destes objetos através de atributos.
Em outros termos, uma classe descreve os serviços providos por objetos e quais
informações eles podem armazenar.
Conceitos base
No conceito de sistemas orientados a objetos
um objeto representa uma entidade que pode ser
física, conceitual, ou de software é uma abstração de algo que possui
fronteira definida e significa para a aplicação.
Dentro da terminologia
das lingagens de programações, um objeto
passa a existir apartir de um “ molde”. Este molde, definido como classe do
objeto, defini os limites, seus atributos e suas funções. Podem ser criados
varios objetos ou instancias de uma classe.
Estado e comportamento
·
Uma
das principais característica a orientação a objeto é o acoplamento de dados e
funções
·
O
estado de um objeto é representado por seus dados ou mais especificamente
atributos
·
O
comportamento de um objeto é representado por seus métodos ou mais
especificamente subs ou functions.
·
Como
por exemplo temos a classe Mamifero que define que um mamífero ( objeto) possui
altura, cor e peso ( atributos) e pode se comunicar ( comportamento) com outros
mamíferos ( objeto)
Encapsulamento
Justamente o
empacotamento dos atributos e dos metodos numa mesma classe. Isto protege os
dados contra corrupsão, pois somente os métodos da classe poderão alterar as
estruturas de dados desta classe em questão.
Mensagem
Os objetos se comunicam
entre si através de mensagens. A mensagem especifica que um determinado método
de um objeto necessita utiliza um ou mais método de outro objeto. Pdem ser
passados objetos como paramentro, opcionalmente algum resultado ou valor pode
ser retornado.
As mensagens especificam que os métodos devem
ser executados não como estes métodos devem ser executados
Quando um objeto A quer
que o objeto B faça uma ação, o objeto A envia uma mensagem ao objeto B: “ A
pede para B fazer ação “ = “ A pede para B executa método 1”
Abstração
Abstração é o exame
seletivo de determinados aspectos de um problema. O objetivo da abstração é
isolar os aspectos que sejam importantes para algum propósito e suprimir os que
não o forem. A abstração deve sempre visar a um propósito, porque este
determina o que é e o que não é importante.
Exemplo de abstração
No exemplo abaixo toda a
característica (Atributo) e comportamento ( métodos) comum a todos os mamiferos
foi abstração na classe abstrata mamiferos.
Classe abstrata não pode
ser instanciada, em outras palavras não se pode criar objetos diretamente de
mamíferos . A classe abstrata serve apenas para encapsular os métodos e
atributos comuns a todos os mamíferos.
A partir da classe
abstrata criamos as classes concretas, que podem ser instanciadas. São classes
que representam um mamífero especifico, que alem de conter todo comportamento e
caracterisca de um mamífero, possui seus próprios. Utilizamos a herança na
orientação a objeto para estrutura esta relação.
Polimorfismo
O polimorfismo permite
que referencias de tipos de classes mais abstratas representem o comportamento
das classes concretas que referenciam. Assim o mesmo método pode
apresentar varias formas, de acordo com
seu contexto. O polimorfismo é importante pois permite que as semântica de um
interface seja efetivamente separada da implementação que representa. O termo
polimorfismo é originário do grego e significa “ muitas formas” ( poli= muitas,
morphos = formas)
Resumo - Analise e Desenvolvimento de
Sistemas
Conceitos Iniciais
Analise de sistema
·
Considerada
a fase principal do ciclo de vida do desenvolvimento de sistemas da informação.
Sendo uma base inicial, qualquer falha cometida terá efeitos em cadeia nas
etapas subsequentes, ou seja, representa o estudo detalhado de uma área de
trabalho gerando assim um processo.
·
Antecede
uma ação que, quase sempre, implica no desenvolvimento de programas integrados
destinados a execução, controle e acompanhamento do processo, criando um
sistema.
Processos
são
uma serie de fenômenos sucessivos com relação à causa e efeito.
O que é preciso para
desenvolver um sistema?
Analisar,
Planejar, Conhecer, Estruturar, Mapear e DFD (Diagrama de Fluxo de Dados).
Analise de Sistemas
Determina
e especifica o que o sistema deve fazer, ou seja, sob quais circunstâncias o
sistema vai operar.
Circunstâncias /
Estrutura do sistema
·
Determinista:
Geralmente sistemas autônomos (dispositivos eletrônicos).
·
Probabilística:
Normalmente sistemas sociais (envolve pessoas).
Diagramas e
Documentação são:
·
Desenhos
gráficos que seguem algum padrão logico.
·
Diagramas
apresentam uma coleção de elementos gráficos que possuem um significado
predefinido.
·
Diagramas
são construídos de acordo com regras de notação bem definida.
Fases do Desenvolvimento
de Sistemas
Concepção,
Transição, Elaboração e Construção.
Requisito:
Condição ou capacidade em que o sistema deve estar de acordo.
Requisito
Funcional: Especifica o comportamento de entrada e saída de um sistema.
Requisito Não Funcional:
·
Descreve
como o sistema é
·
Usabilidade
·
Desempenho
·
Software
amigável para usuário
·
Confiabilidade
Possíveis definições
para DFD
·
Um
DFD pode ser entendido como uma rede que ilustra como circulam os dados no
interior do sistema.
·
Diagrama
gráfico, baseado apenas em quatro símbolos que mostram a estrutura do sistema e
todas as relações entre os dados. Os processos que transformam esses dados é o
limite entre o que pertence ao sistema e o que esta fora dele.
DFD – Componentes:
·
Entidades:
Fornecem entradas ao sistema (fontes) ou recebem dados do sistema
(terminadores).
·
Processos:
Transformam o fluxo de entrada em fluxo de saída.
·
Fluxos
de Dados: Modelam a passagem de dados, indicando sentido e nome do fluxo
associado.
·
Depósitos
de Dados: Responsáveis por armazenar/guardar a informação (dados).
Comentários
Postar um comentário