O RUP

Voltando a falar sobre Engenharia de Software, iniciaremos aqui uma série de posts sobre um processo de desenvolvimento bastante difundido no mercado - o RUP.

O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.

Essa metodologia é tida pelo mercado, como "pesada" em nível de atividades,processos, artefatos, etc, porém por ser uma metodologia adaptável, pode se adequar a projetos de qualquer magnitude.

O Rup toma como premissa 6 práticas de engenharia de software. São elas:

• Desenvolvimento iterativo;
• Gerenciamento de requisitos;
• Arquitetura baseada em componentes;
• Modelagem utilizando a UML como ferramenta;
• Melhoria contínua de processos e produtos de software;
• Configuração e gerenciamento de mudança.

Além dessas práticas existem outras premissas que o RUP segue:

• Desenvolvimento orientado por caso de uso - Os casos de uso são o alicerce para o processo;
  
• Configuração de processo - O processo é adaptável, podendo ser usado em pequenos e grandes projetos;
  
• Suporte a Ferramentas - A Rational possui uma suite de ferramentas com objetivo de apoiar o processo.
  

O modelo RUP é constituído por três entidades fundamentais: trabalhadores (papéis), atividades e artefatos.

Fluxogramas relacionam as atividades e os papéis em sequências que produzem valiosos resultados.

Recomendações, modelos de documento e ferramentas complementam a descrição do processo fornecendo orientação detalhada aos profissionais que usam o RUP.

O modelo do RUP se baseia no modelo incremental e iterativo e procura resolver problemas clássicos do desenvolvimento de sistemas como: a mudança de requisitos, a falta de gerência de riscos, o estouro de prazos, a falta de produtividade e a falta de atualização de documentos.

Esses problemas são resolvidos pelo RUP, promovendo o desenvolvimento iterativo, o controle do processo através de fases e fatos e focando nas mudanças de ciclo das atividades de desenvolvimento.

O processo conta com 4 fases:

• Concepção - levantar requisitos, definir o escopo do produto;
  
• Elaboração - analisar os requisitos, modelar o produto a ser entregue e definir a arquitetura sobre a qual o produto será construído;
  
• Construção - Implementação do produto;
  
• Transição - produz a entrega do produto final.
  

Como o produto de software passa por vários ciclos de evolução, a cada iteração se passa por essas 4 fases produzindo-se sempre novas gerações mais evoluídas do produto em questão.

Em cada uma dessas 4 fases, são realizadas uma série de atividades(requisitos,projeto,implementação e avaliação) e essas atividades são revisitadas a cada iteração.

Na imagem abaixo, temos uma noção do processo como um todo e da intensidade das atividades no decorrer das fases do processo.


O RUP é entregue aos profissionais como um Web site interativo no qual se explica todo o método. Além desse web site, encontra-se informação sobre o RUP no livro "Introdução ao RUP Rational Unified Process" do autor Philippe Kruchten, traduzido e publicado pela editora Ciência Moderna.

Nos próximos posts, vamos falar detalhadamente sobre cada uma das fases presentes no processo de desenvolvimento de software proposto pelo RUP.

Até lá!

Projeto Físico de Banco de dados

Após a criação do modelo lógico de banco de dados, partimos para a construção do modelo físico, ou seja, produzimos um desenho com a definição das tabelas e de suas colunas com os tipos de dados, de seus índices , visões, relacionamentos, etc.

Cabe aqui colocarmos algumas regras para criação das tabelas.

Quando temos um relacionamento um para um entre duas entidades, devemos avaliar a necessidade de criarmos duas tabelas. Geralmente quando se tem um relacionamento deste tipo entre duas entidades cria-se apenas uma tabela.

Para os relacionamentos um para muitos entre duas entidades, devemos criar duas tabelas onde a chave primária ficará do lado um e a chave estrangeira no lado muitos.

Nos relacionamentos muitos para muitos, além das duas tabelas representando as duas entidades que se relacionam, cria-se uma terceira tabela que recebe a chave das duas tabelas criadas para as entidades em questão.

No caso de entidade com auto-relacionamento um para muitos, cria-se uma tabela com uma chave estrangeira que receberá valores da chave primária da própria tabela.

Para auto-relacionamento muitos para muitos cria-se duas tabelas onde um delas recebe a duas chaves de uma mesma tabela.

Em casos de relacionamento ternário, utiliza-se a tabela associativa criada para associar tabelas cujo relacionamento é muitos para muitos inserindo uma nova chave a essa tabela.

Em caso de Generalização/Especialização, podemos optar por duas alternativas. A primeira é adicionar os atributos das entidades especializadas na tabela da entidade genérica. A segunda é criar uma tabela para a entidade generalizada e tabelas para as entidades especializadas.

Após a criação das tabelas devemos definir os tipos de dados das colunas que as constituem.

Após a conclusão do modelo físico, devemos elaborar um script em linguagem SQL para a criação das tabelas no banco de dados. Existem uma série de ferramentas de apoio que auxíliam ao analista na elaboração desses scripts. Erwin, Power Designer são alguns exemplos de ferramenta CASE para este propósito.

É possível também realizar o que chamamos de engenharia reversa, ou seja, a partir de um banco de dados já implementado, gerar os modelos físico e lógico do banco de dados.

Bom, é isso aí!

Abraço!

HUGO

Projeto lógico de Banco de dados

No último post falamos sobre alguns conceitos importantes sobre bancos de dados. Aqui iremos apontar quais etapas devem ser realizadas para criação de um modelo conceitual de um banco de dados.

O projeto lógico de banco de dados consiste na análise e modelagem utilizando o modelo de entidade e relacionamento e normalização de dados.

Copiando Peter Chen, as principais etapas para construção de um projeto lógico de banco de dados são:

1. Identificar as entidades;
2. Identificar os tipos de relacionamentos entre essas entidades;
3. Desenhar o diagrama de entidade X relacionamento prevendo os itens acima;
4. Identificar os atributos que as entidades terão;

Nomalização de dados

A normalização é o processo pelo qual são aplicadas regras a um conjunto de dados para se obter uma estrutura de dados quase livre de redundâncias. Ao final do processo de normalização, deve-se valida-lo com o modelo de entidade e relacionamento.

Esse processo pode ser feito em até seis etapas, mas geralmente, ao se chegar a terceira etapa( terceira forma normal) já se obtem um modelo de dados estável.

As três fases de normalização de dados são:

• primeira forma normal - O objetivo aqui é eliminar grupos de dados repetitivos da estrutura e coloca-los em uma nova entidade.
  

Vamos analisar uma nota fiscal. Nesta existem uma série de produtos (itens repetitivos). Neste caso vamos criar uma nova entidade PRODUTO para inclusão desses itens.

• segunda forma normal - Deve-se localizar dados que não dependa única e exclusivamente da chave primária da entidade em questão. Ao se identificar grupos de dados independentes dessa chave deve-se separá-los em outras entidades.

Os dados do cliente na nota fiscal não dependem única e exclusivamente da chave primária da Nota fiscal, assim devem ser colocados em uma nova entidade (CLIENTE).

• terceira forma normal - Nessa etapa, devemos localizar atributos com dependência transitiva. São atributos que podem ser obtidos através de outros e que portanto não precisam existir fisicamente. Deste modo devem ser excluídos.

No exemplo da nota fiscal tempos o campo valor total. O valor desse campo é obtido através da soma do valor unitário de cada produto na nota, portanto não há a necessidade de se criar um campo para guardar esse valor.

Após a construção do modelo conceitual, partimos para a construção do modelo físico, e para a criação do script de criação dos objetos que constituirão o banco de dados

Conceitos de Banco de dados

Um sistema de informação tem o objetivo de receber dados, processa-los e gerar informação.

O usuário "entra" com dados, o sistema "processa" esses dados e produz uma "saída".

Mas vamos com calma! Qual é a diferença entre dado e informação? De forma simplista, podemos dizer que o dado é um fato ou característica isolado referente a algum objeto, coisa ou entidade. Já a informação é um conjunto de dados relacionados. Por exemplo, uma pessoa possui nome, telefone, endereço entre outros dados. O nome é um dado, já o conjunto nome, telefone, endereço é uma informação.

Todo o processamento de dados é feita na memória principal do computador, porém como sabemos essa memória é volátil, ou seja, é apagada quando se desligar o computador e é aí que entra em cena os bancos de dados.

Você poderia dizer o seguinte: por que não gravar essas informações em arquivos? Bom, respondendo a essa pergunta com outra pergunta. Como organizar esses arquivos se o volume das informações for muito grande e com taxa de crescimento for constante? O banco de dados é a solução para o problema.

Armazenar informações organizadas e recuperá-las sem faltar um pedacinho sequer, sempre que necessário é a função principal dos bancos de dados.

Todo mundo que usa telefone costuma ter uma agenda telefônica. Nela cada amigo tem nome, endereço, número da linha, aniversário e nos tempos atuais e-mail e quando precisamos ligar para alguém, vamos à letra incial do nome e buscamos o número do telefone.

Essa "agendinha" expressa bem o conceito de banco de dados - um armazém de informações relevantes, organizadas de maneira coerente e lógica, que precisa ser recuperadas com frequência.

Esse universo envolve conceitos importantes que precisamos entender para torna-lo útil. Vamos a eles:

Sistema de gerenciador de banco de dados e Banco de dados

É importante não confundir os conceitos de sistema gerenciador de banco de dados e banco de dados.

O primeiro refere-se a programas que auxiliam ao usuário na tarefa de manipular e administrar os dados contidos em um banco de dados. Esses programas promovem os controles de acesso, redundância, integridade e o mecanismo de cópias de segurança dos dados presentes em um banco de dados.

Se você perguntar a um DBA com que banco de dados ele trabalha ele poderá responder que trabalha com o MySQL, Oracle, Sql server e por aí vai, porém se você fizer essa pergunta a um analista de sistemas ou a um analista de negócios, este poderá lhe responder que trabalha com o banco de dados do RH ou com o banco de dados acadêmico, por exemplo.

Modelagem de dados

A modelagem de dados é o processo pelo qual trabalham-se os dados de modo a promover estruturas de amazenamento estáveis. Esse processo se por meio da criação de modelos conceituais de entidade e relacionamento ou pela nomalização de dados, fazendo com que essas estruturas possam evoluir com o tempo, sem prejudicar o desenvolvimento de sistemas.

Entidade

Entende-se como um grupo de coisas semelhantes. Essas coisas podem ter uma existência física (pessoa, carro) ou abstrata (pedido, ordem de serviço). Cada entidade possui diversar instâncias do objeto que o representa.

Quando se transpõe a entidade para um modelo físico, criamos uma tabela. Já no modelo Orientado a objeto, temos o que chamamos de classe.

Atributo

O atributo é um qualificador lógico de um objeto. É um dado e como tal, serve para descrever o caracterizar o objeto em questão.

Quando se transpõe para o modelo físico o atributo torna-se um campo. No modelo orientado a objeto é conhecido com propriedade ou atributo mesmo.

Tupla

Uma tupla é o conjunto de características do objeto. No modelo físico uma tupla é um registro presente em uma tabela. No modelo orientado a objetos, dizemos que esta é uma instância de um objeto.

Tabela

A tabela é uma estrutura composta por registros compostos por linhas e colunas. A linha representa um objeto do mundo real e as colunas servem para qualificar esse objeto.

Chave

A chave é um qualificador único de um registro. É o campo escolhido para identificar exclusivamente um registro e por conta disso esse campo não poderá conter valores em branco ou repetidos.

Vamos imaginar qual atributo de uma pessoa seria a melhor opção para ser um chave. O campo nome com certeza não seria a opção a ser escolhida visto que existem pessoas com nomes homônimos. O CPF talvez seja um atributo candidato, pois é um documento obrigatório para uma pessoa adulta, porém esse documento não é obrigatório para crianças.

Nos casos em que nenhum dos atributos sejam qualificados para ser o campo chave do registro, deve-se criar um campo específico para isto (ex: matrícula). As chaves podem ser classificadas nos tipos abaixo:

• Primária - Classificam unicamente um registro. Toda tabela deve possuir uma chave primária.
• Estrangeira - Servem para relacionar as tabelas do banco de dados. Por exemplo temos duas tabelas: CLIENTE e NOTA_FISCAL. Cada tabela tem um chave primária , porém para relacionar essas tabelas a tabela nota fiscal deverá possuir a chave estrangeira CLIENTE que possuirá como valor um código de um cliente.
• Secundária - São os demais campos do registro que possui a função de subclassificar esses registros. É muito utilizado nos índices de uma tabela (falaremos sobre eles daqui à pouco).

Relacionamento

Os objetos do mundo real apesar de distintos guardam um certo grau de relacionamento com outros objetos.

Voltando ao exemplo do cliente/nota fiscal notamos que existe uma relação de interdependência entre essas duas entidades, ou seja, para emitirmos uma nota fiscal é necessária a existência de um cliente. A essa interdependência, damos o nome de relacionamento e este pode ser classificado de duas formas:

• Opcionalidade - indica se é obrigatória ou não a ocorrência ou indicação de um registro no outro.
• Cardinalidade - A cardinalidade indica quantas ocorrências de um registro podem se relacionar com outro registro.

Existem 3 tipos de cardinalidade:

• Um para um (1:1) - é quando cada tupla de uma entidade está relacionada a apenas uma tupla de outra entidade.
• Um para muitos (1:M) - é quando cada tupla de uma entidade pode estar relacionada a muitas tuplas de uma outra entidade.
• Muitos para muitos (M:M) - Neste caso várias tuplas de uma entidade podem estar relacionadas a várias tuplas de uma outra entidade.

Integridade referencial

A integridade referencial é o mecanismo utilizado pelos gerenciadores de bancos com o objetivo de manter a consistência dos dados do banco.

Digamos que um usuário tente emtir uma nota fiscal com um código de cliente inexistente? Ou ainda apagar registro de um cliente que possui diversas notas fiscais cadastradas? Como ficaria a consistência dessas tabelas? Um bom SGBD deve garantir a integridade referencial do banco.

Restrições (Constraints)

As restrições são utilizadas para melhorar a qualidade da informação guardada nas tabelas do banco. Já falamos sobre duas restrições: chaves primárias e estrangeiras, contudo existem outras restrições muito importantes:

• Nulos - servem para determinar se é permitido a inserção de um valorou não em um determinado campo;
• Exclusivos (unique) - servem para determinar se o campo pode ou não receber valores repetidos;
• Padrão - Serve para informar um valor padrão quando um valor não é informado pelo usuário;
• Domínio - Serve para limitar os valores a serem inseridos em um campo. Exemplo: O campo Sexo só pode receber dois valores (Masculino ou Feminino).
  

Transação

Sempre que ocorrer a alteração no conteúdo de uma ou mais tabelas de um banco de dados. Deste modo sempre que houver uma inclusão, alteração ou exclusão em um registro é gerada uma transação. O usuário ou o sistema gerenciador de banco de dados, nomento da operação, pode optar pela efetivação (COMMIT) ou pelo abandono da mesma (ROLL-BACK).

Procedimentos armazenados

São pequenos códigos executados em um banco de dados que fim guardados para posterior utilização. São eles:

• Stored Procedures - código que realiza operações no banco de dados. Não retornam valor;
• Functions - idêntico a uma Stored procedures exceto por retornar valor;
• Triggers - são procedimentos disparados por eventos (a inclusão, alteração ou exclusão de um registro).

Algum desses conceitos são vistos como objetos em um banco de dados (tabelas, constraints, índices, stored procedures, usuários etc).

Bom, acho que com esses conceitos já dá para praticarmos um pouco de modelagem de dados, mas isso será assunto para outro post.

Modelos Evolucionários

Dando continuidade a explanação sobre modelos prescritivos de software, iremos nesse post falar sobre os modelos evolucionários de desenvolvimento de software.

Como o próprio nome já sugere os modelos explanados aqui são explicitamente projetados para acomodar um produto que evolui com o tempo.

A cada iteração, os modelos evolucionários tem por objetivo produzir uma versão melhor e mais completa do software.

Vamos a eles:

Modelo de Prototipagem

A prototipação é uma ferramenta que pode ser usada em qualquer um dos modelos apresentados até agora

Essa técnica auxilia o engenheiro de software e o cliente aentenderem melhor o que deve ser construído quando os requisitos estão confusos.

Um protótipo é uma espécie de versão preliminar do software.Pode ser um programa ou no papel e concentra-se na representação dos aspectos dosoftware que são visíveis para o cliente.





Modelo Espiral

O modelo espiral é uma evolução dos modelos vistos anteriormente valorizando os pontos positivos desses modelos e desprezando o pontos negativos.

O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Um ciclo se inicia com a determinação de objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos.

Na segunda tarefa, avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto.

Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata.

Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.


Bom gente, acho que já falamos muito sobre os modelos prescritivos de desenvolvimento? Nos próximos posts vamos falar um pouco sobre um processo de desenvolvimento de software muito difundido no mercado - O RUP.

Inté!

Modelos prescritivos de desenvolvimento de software

Na Engenharia de Software, processo é um conjunto de passos parcialmente ordenados, cujo objetivo é atingir uma meta: entregar um produto de software de maneira eficiente, previsível e que atinja as necessidades de negócio. Geralmente inclui "atividades" como análise de requisitos, programação, testes, entre outras tarefas. Conlui-se portanto que um processo é composto por atividades relacionadas e os modelos servem para dar uma visão de como é um processo. Um modelo de processo de software define o que deve ser realizado em cada fase do desenvolvimento e dá as instruções de como realizar essas atividades. Ele serve como um guia, um roteiro para a execução de um processo de desenvolvimento. Um modelo descritivo retrata como um processo é executado em um ambiente em particular. Já um "modelo prescritivo" retrata como um processo deveria ser executado. Sendo assim um modelo prescritivo é uma espécie de recomendação que pode ser adaptada ou melhorada (veja os modelos de melhoria de processo CMMI e SPICE) pela empresa de software que for adotá-la. Esses modelos abrangem três elementos principais:

• Processos: determinam quais são as tarefas necessárias e em que ordem elas devem ser executadas.

• Métodos: fornecem detalhes fundamentais de como fazer para executar as tarefas necessárias.

• Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos processos e métodos.

Existem um conjunto de atividades que aparecem na maioria dos modelos de processos prescritivos de software, diferindo-se apenas com relação ao fluxo de trabalho. São elas:

1. Comunicação: levantamento de requisitos em colaboração com o cliente.
2. Planejamento: estabelece as tarefas, os riscos, os recursos, os produtos e um cronograma.
3. Modelagem: criação de modelos que permitam ao desenvolvedor entender melhor o projeto e seus requisitos. Ações: Análise – modelos de especificação de requisitos e Projeto – modelos de especificação de projeto.
4. Construção: geração de código e testes.
5. Implantação: entrega do software ao cliente.

Bom, mas vamos deixar de bla bla bla e falar do que realmente interessa - Os modelos prescritivos de desenvolvimento. MODELO EM CASCATA O modelo em cascata é o modelo prescrito mais antigo e por isso é considerado um modelo clássico. Ele sugere uma abordagem sequencial para as atividades do processo. Projetos reais raramente seguem o fluxo seqüencial, pois é difícil estabelecer todos os requisitos inicialmente e por conta disso o modelo em cascata possui uma série de limitações ou desvantagens:

• Uma versão executável do software só fica disponível no final do processo.
• Nesse modelo ocorrem o que chamamos de estados de bloqueio: membros da equipe ficam esperando outros membros terminarem a sua parte.
• É adequado quando os requisitos são bem entendidos, como em aperfeiçoamentos de um sistema existente.

MODELO INCREMENTAL O modelo incremental pode ser considerado uma evolução do modelo em cascata. Este modelo é composto pelas atividades do modelo em cascasta porém estas atividades são realizadas repetidamente, ou seja, de forma iterativa. Cada seqüência produz incrementos do software passíveis de serem entregues, fornecendo assim, progressivamente mais funcionalidade ao primeiro incremento que é chamado de núcleo de produto. Esse modelo é particularmente útil quando não há mão-de-obra/recursos disponíveis para uma implementação completa. MODELO RAD (Rapid Application Development) No caso da equipe ser grande, um modelo possível é o modelo RAD. Ele é recomendável quando uma aplicação pode ser modularizada. Desvantagens do modelo RAD:

• Exige pessoal suficiente para criar várias equipes RAD.
• Desenvolvedores e clientes têm que estar comprometidos com atividades rápidas.
• Exige que o sistema seja modularizável.

No próximo post falaremos sobre outros modelos. Abs, HUGO

Diagrama de Implantação

O diagrama de implantação é utilizado para descrever uma visão da arquitetura a ser utilizada, ou seja, mostra a integração entre a parte física (hardware) da solução de software.

Diagrama de Componentes

O diagrama de componentes é utilizado para exibir como os módulos de um sistema são interligados.

Diagrama de Atividades

O diagrama de atividades é semelhante a um fluxograma, ou seja, esse diagrama é focado no fluxo de controle de uma atividade.

Preocupa-se em descrever os passos a serem seguidos para a conclusão de um método e não de um processo (isso é responsabilidade do digrama de sequência e de colaboração).

Diagrama de Estado

O diagrama de Estados procura exibir as mudanças de estado dos objetos dentro de um processo.

Diagrama de Colaboração

O diagrama de colaboração é muito parecido com o diagrama de sequência, pois preocupa-se com a comunicação entre os objetos entretanto, este diagrama não leva em consideração a temporalidade em que as "coisas" (troca de mensagem) acontecem.

Diagrama de Sequência

O objetivo do diagrama de sequência é determinar a ordem temporal ou a sequencia de eventos que ocorrem em um determinado processo.

Nesse diagrama é possível se visualizar as mensagens trocadas entre os objetos, as restrições impostas para a troca dessas mensagens, os métodos que são chamados, a interação entre os objetos e em que momento essas coisas acontecem.

Diagrama de Objetos

O diagrama de objetos complementa o diagrma de classes representando os objetos e seus estados em um determinado momento.

É recomendável criar vários diagramas de objetos enfocando pequenas partes do diagrama de classe evitando assim um diagrama poluído.

Conceitos

Classes Entity - Classes que mantem as informações apenas na memória principal.

Classes persistentes - Classes que devem obrigatoriamente preservam suas informações fisicamente, ou seja, em memória secundária.

Esteriótipos de classe

<<>> usado para indicar classes do tipo Entity
<> indica que a classe é uma interface
<> indica que a classe ser para ligar a interface a outras classes

O Diagrama de Classes

Neste post vamos falar sobre outro diagrama da UML - O diagrama de classes.

Sua função é proporcionar uma visão das classes que comporão um sistema, seus atributos e métodos, além do relacionamento entre as classes e como essas classes se complementam e se relacionam entre si.

Tem se também uma representação da visibilidade dos atributos e métodos que formam a classe.

É uma evolução do diagrama de entidade e relacionamento, pois além das entidades (atributos) , se representa nesse diagrama os comportamentos das classes (métodos).

Observação importante: Esse diagrama não se preocupa com a sequência em que as funcionalidades irão ocorrer, sendo está responsabilidade de outros diagramas.

Perspectivas

Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador diferente. São elas:

• Conceitual - Representa os conceitos do domínio em estudo.(Perspectiva destinada ao cliente)

• Especificação - Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados (Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto).

• Implementação - A mais utilizada de todas, aborda vários detalhes deimplementação, tais como navegabilidade, tipo dos atributos, etc.(Perspectiva destinada ao time de desenvolvimento).

Relacionamentos

Tem a função de representar os relacionamentos entre as classes mostrando como elas colaboram umas com as outras. Existem 6 tipos de relacionamento:

• Associação (unária, binária, ternária)
• Agregação (semelhante ao relacionamento todo-parte)
• Composiçao (usado para representar um vínculo mais forte entre as entidades, ou seja um nível de dependência maior entre as classes)
• Generalização/especialização - relacionamento entre superclasses e subclasses.
• Dependência - Uma classe dpende da outra.
• Realização - utilizada para representar os relacionamentos entre interfaces e classes

Associação Unária



Associação Binária

Classes Associativas - Devem ser criadas quando a multiplicidade é *..* (muitos para muitos)


Agregação - Um pedido é composto por um ou mais itens. Um pedido compõe vários itens de pedido

Composição - Uma revista possui uma ou mais edições e no mínimo 6 e no máximo 10 artigos



Abaixo um diagrama para o sistema bancário:

Repare que não é necessário representar chaves primárias e nem estrangeiras nesse diagrama. Isso fica implícito.

A UML

A UML
Conforme mencionado em posts anteriores, a análise estruturada/essencial se utilizava dos diagramas de contextos e de fluxo para modelar conceitualmente os sistemas.

Com o surgimento da programação orientada a objetos, novos diagramas foram criados possibilitando ao arquiteto de software prover várias visões sobre os componentes dos sistemas.

A UML é uma proposta da OMG (Object Management Group) para padronização de modelos conceituais de software. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML. Falaremos do RUP em outra ocasião.

Até sua versão 1.x a UML provia 8 diagramas (caso de uso, classes, sequência, colaboração, gráfico de estados, atividades, componentes e implantação).

Houve um incremento de mais três diagramas na versão 2.0 e uniu-se dois diagramas totalizando assim, um total de 10 diagramas.

Esses diagramas podem ser separados em duas categorias. Estruturais ou estáticos e Comportamentais ou dinâmicos..:

* Estruturais (objetos, classes, componentes, pacotes)
* Comportamentais (Caso de uso, atividades, estado, colaboração, sequência, tempo).

A figura abaixo mostra a hirarquia entre esses diagramas.



É possível que seu navegador não suporte a exibição desta imagem. Elementos acessórios

Existem elementos acessórios que podem estar presentes em todos os diagramas definidos pela UML são eles:

* Nota - sua função é apresentar textos explicativos sobre os outros elementos presentes nos digramas;



* Pacotes - permitem organizar elementos em grupo. É muito utilizado em sistemas extensos ou que possuam subsistemas envolvidos. Os pacotes podem se relacionar (um pacote pode depender de outro para que um sistema possa funcionar);



* Estereótipos - possibilitam ao analista estender a UML. Sua função é enfatizar características diferentes para um mesmo tipo de elemento. Existem dois tipos de estereotipo (de rótulo e de gráfico). O estereotipo de rotulo enfatiza que um caso de uso se trata de um processo, diferenciando o mesmo dos demais casos de uso. Já o estereotipo gráfico serve para indicar que um objeto representa uma interface entre usuário X sistema.


Diagrama de Casos de uso


O diagrama de casos de uso corresponde a uma visão externa do sistema e representa graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem como objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema, ou seja, a finalidade de um Diagrama de Caso de Uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.

Componentes: atores, casos de uso e suas associações. A seguir, a figura mostra um exemplo desse tipo de diagrama.




Repare na simbologia utilizada. A elipse representa uma funcionalidade (um caso de uso), o boneco palito um ator e as setas ou linhas as associações de interação entre atores e casos de uso além de setas que expressam certo grau de dependência entre os casos de uso.

Existem dois tipos de grau de dependência:

* Inclusão - quando uma funcionalidade depende obrigatoriamente de outra;
* Extensão - quando uma funcionalidade usa opcionalmente uma outra funcionalidade.

Como sugestão fica aqui um curso muito bom e gratuíto disponível na Internet  Entendendo casos de uso da empresa aspercom.

Nos próximos posts falarei dos demais diagramas.

Até mais!

HUGO

Análise Orientada a Objeto

Uma das principais atividades de um analista é a análise de um problema e a modelagem conceitual de soluções na forma de sistemas. Para isto, o analista se utiliza de ferramentas e técnicas de apoio de modo a aumentar eficiência e a eficácia na produção de software.

Como o nome já sugere, a modelagem compreende a produção de modelos capazes de descrever a solução proposta pelo analista de forma conceitual. Deste modo, é possível se promover a comunicação entre o analista e o cliente que encomendou o produto de software em questão.

Conforme citado no post anterior, a análise estruturada e essencial faz uso dos diagramas de contexto, de diagramas de fluxo de dados e de diagramas de entidade e relacionamento. A modelagem orientada a objetos se utiliza de modelos constantes na UML, mas esse assunto merece um post a parte.

O primeiro passo para se aprender a modelar um sistema orientado a objeto é conhecer o que chamamos de paradigma da orientação a objetos. Entende-se por paradigma a representação de um padrão a ser seguido, um modo de se pensar sobre, encarar algo ou agir de acordo com algum contexto. Profundo não! Sem frescura, é conhecer os conceitos dos elementos que constitui a Orientação a objetos (classes, objetos, herança, polimorfirmo, encapsulamento entre outros).

Bom então "bora começar do começo"

Objetos

Boa parte de nosso entendimento e relacionamento com o mundo se dá por meio do conceito de objetos. Ao observarmos as coisas ou seres que existem ao nosso redor, há uma tendência natural de tentarmos identificar o que são essas diferentes entidades, ou seja, como aparentam ser e que comportamento tem.

Um carro possui em comum quatro rodas e tem como comportamento se locomover. Apesar de possuir características comuns, os objetos possuem características que os identificam de forma única. O número de chassi de um carro nunca se repete por exemplo. São estas características que definem o "estado" a identidade do objeto.

Classes

Já as características comuns como cor, potencia, quantidade de lugares, etc nos permitem categorizar /agrupar/ "classificar" os objetos em conjuntos. A esses conjuntos damos o nome de classes. É natural para facilitarmos nosso entendimento, criarmos uma classificação para as coisas que embora seja distintas possuem características comuns.

Na pratica, podemos definir uma classe como sendo uma estrutura que uni as variáveis e os procedimentos presentes em um programa.

Podemos dizer que um objeto é uma "instância" de uma classe.

Uma classe é uma estrutura composta por atributos (características) e métodos (comportamentos).

Quando instanciamos um objeto de uma classe, atribuímos valores iniciais aos atributos desse objeto através de um método especial chamado de método construtor Para limpar esse objeto da memória principal do computador utilizamos o método conhecido como destrutor.

Encapsulamento

O encapsulamento indica que podemos utilizar um objeto conhecendo apenas a sua interface, isto é, sua aparência exterior sem conhecer seu funcionamento interior. Por exemplo, você envia ordens a um carro quando o está dirigindo sem precisar conhecer o que rola "por trás dos bastidores". Quando você liga um carro que atividades esse carro realiza para atender a este comando!

O estado de um objeto só pode ser alterado através de seus comportamentos visíveis.

Os membros de uma classe (atributos e métodos) possuem indicadores de visibilidade conhecidos como modificadores de acesso. Através deles, determinamos o nível de acesso desses membros.

Um membro privado só pode ser visualizado pela classe que o contém.

Um membro protegido só pode ser acessado pela classe que o contém e por classes que herdam esses membros.

Um membro público pode ser acessado por qualquer classe.

Os valores dos atributos de um objeto devem ser modificados através de seus métodos públicos, ou seja, através de seus "métodos setadores".

Um método definido como estático pode ser invocado sem a necessidade de se instanciar um objeto da classe.


Herança

A herança é o mecanismo que permite a criação de classes mais específicas a partir de classes mais genéricas. É esse paradigma que promove a reutilização ou reaproveitamento de caracteríscas e comportamentos.

Um carro de passeio e um utilitário são classes mais específicas que possui características comuns herdadas de uma classe mais genérica - a classe carro.

No final das contas a herança acaba criando uma hierarquia entre classes mais genéricas(superclasses) e classes mais especializadas (subclasses).

Cabe aqui falar de outros modificadores de acesso.

Classes abstratas que não podem ser instanciadas podendo apenas ser herdadas.

Classes finais não podem ser herdadas.

Os métodos abstratos são aqueles que são declarados numa superclasse e implementados em suas subclasses.

Uma interface é uma estrutura que contem apenas a assinatura de métodos, porém o contéudo desses métodos é escrita nas classes que implementam essa interface.

Polimorfismo

A palavra polimorfismo sugere o conceito de várias formas. Esse paradigma nos permite redefinir comportamentos. Todo carro possui o comportamento "passar marcha" , entretanto um carro com câmbio automático realiza essa tarefa de maneira diferente de um carro com câmbio mecânico.

Na programação orientada a objeto o polimorfismo é promovido através da sobrecarga e da sobrescrita de métodos.

A Sobrescrita refere-se apenas a metodos das classes filhas. É o ato de mudar o comportamento de um método em uma subclasse.

A Sobrecarga refere-se tanto a mesma classe quanto a classe filha. É o ato de ter-se mais de um método com o mesmo nome, porém com lista de parâmetros diferentes, ou seja, com assinaturas distintas.

Não existe sobrescrita em métodos da mesma classe, isso não faz sentido. Por outro lado existe sobrecarga, facilitando o programador com sua API.

Métodos finais não podem ser sobrescritos.

Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento ( métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. Esses objetos se comunicam através da troca de mensagens, ou seja, atráves da solicitação de serviços.

Bom, tentei aqui explanar uma série de conceitos importantes. No próximo post vou falar sobre UML.

Análise Estruturada X Essencial

Eu diria que a análise de sistema é composta de uma série de técnicas e ferramentas que tem por objetivo auxiliar ao analista de sistemas na tarefa de modelagem.

Uma das ferramentas preferidas dos Analistas são os diagramas, que possibilita ser ter uma visão conceitual de como o sistema funcionará. Afinal, uma imagem fala mais do que mil palavras.

O modelo de análise estruturada formalizado na década de 70 e popularizado principalmente por [GANE,1983] e [DeMARCO,1989]. foi e ainda é bastante utilizada por analistas de sistemas para criar uma visão conceitual dos sistemas.

Fundamentada no princípio da decomposição funcional, ele tem como objetivo a modelagem utilizando-se, para esse fim, de um conjunto de ferramentas, sendo o Diagrama de Fluxo de Dados (DFD) e o Dicionário de Dados (DD) as principais delas.

O método de decomposição recomendado é baseado na busca pela menor taxa de transferência de dados entre os sub-processos dos processos que estão sendo analisados, o que levaria, por conseqüência, a um modelo da organização decomposta em módulos funcionalmente coesos, ou seja, módulos que têm uma única função.

A principal crítica à análise estruturada é a não replicabilidade dos requisitos resultantes da análise, caso fosse feito um experimento em que diversos analistas fossem incumbidos de analisarem o mesmo sistema. Isso porque o processo de decomposição utilizado depende da abordagem de cada analista particularmente (dos seus pressupostos e de suas experiências anteriores ao projeto em questão) e das coincidências de informações oriundas das pessoas que compõem a organização social sob análise.

Além disso, a grande quantidade de artefatos produzidos tornavam o projeto muito volumoso.

A Análise Essencial de Sistemas pode ser considerada uma evolução da análise estruturada.

A abordagem da análise essencial de sistemas utiliza-se das mesmas ferramentas de modelagem da análise estruturada, mas os mecanismos são diferentes. Ao invés de uma decomposição do mais geral para o mais específico ("top-down") o método prevê que sejam identificados, inicialmente, os eventos externos aos quais espera-se que a organização social em questão responda, sendo derivadas então as ações (ou funcões) em resposta a esses eventos e, posteriormente, os eventos gerados internamente e também as respectivas ações.

A expressão "essencial" deve-se ao fato de que não serão consideradas quaisquer restrições tecnológicas, ou seja, como se a tecnologia disponível fosse perfeita o suficiente para suportar quaisquer questões relacionadas à captura ou mixagem dos dados, permitindo que seja possível concentrar-se somente sobre as questões essenciais do sistema sob análise.

Com a evolução dos paradigmas de programação e consequentemente com a evolução das linguagens voltadas para o desenvolvimento de sistemas, novas técnicas e modelos foram criados possibilitando ao analista prover vários tipos de visão sobre os sistemas. Essa evolução promoveu o surgimento da UML, padrão altamente difundido e aceito pelo mercado. Próximo passo: O paradigma da programação Orientada a Objetos e a UML.

Vamos que vamos!

A Engenharia de software

Toda ciência possui áreas de conhecimento e na computação a questão não poderia ser diferente.

A Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade.

Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades.

Além disso, a engenharia de software oferece mecanismos para se gerenciar o processo de desenvolvimento de um sistema de informação.

A esses mecanimos damos o nome de metodologias de desenvolvimento de software. Uma metodologia de software é composta por uma sequência de atividades com a finalidade de produzir produtos de software de qualidade. Esse conjunto de atividades é conhecido como ciclo de vida do processo.

Existem uma série de modelos de processos de desenvolvimento, ou seja, uma série de ciclos de vida consagrados na Engenharia de Software. Cabe aqui citar os modelos de ciclo de vida em cascaca e o modelo espiral.

Outro assunto que não podemos deixar de mencionar é que a evolução dos paradigmas de programação promoveram uma evolução na modelagem de sistemas. Uma prova disso é o surgimento da análise estruturada, depois da análise essencial e mais tarde da análise orientada a objetos.

Nos próximos posts pretendo escrever mais a respeito desses assuntos.

Evolução dos paradigmas de programação

Existe um ditado que diz “Quem não aprende com o passado está fadado a repeti-lo”, assim é importante contarmos aqui uma historinha sobre a evolução da programação de computadores.

Como se sabe, um processador de computador só entende o que é zero e um, ou seja, uma CPU só consegue interpretar a linguagem binária.

Nos primórdios da computação, a única alternativa para se programar um computador era jogar o código binário de programas na memória principal do computador. A probabilidade de erros era grande, a manutenção de código era impossível e o reuso um sonho distante. Essa abordagem é conhecida como programação binária.

Para resolver essas questões surgem as primeiras linguagens de programação e conseqüentemente os compiladores (responsáveis pela conversão da linguagem natural em linguagem de máquina). Com estas linguagens era possível se criar programas com estruturas monolíticas responsáveis por executar todas as tarefas de um programa.

Nasce a programação linear. A manutenção desses programas não era tarefa simples e seu código era praticamente ilegível, dificultando até o planejamento da uma solução de um problema utilizando programas deste tipo.

Era preciso dividir para conquistar. Foi com o surgimento de linguagens de programação capazes de representar o conceito de procedimentos que se resolveu esse problema.

Surge então o conceito programação procedural que permitiu a divisão do código dos programas em procedimentos, estruturas semi-autônomas e reutilizáveis nos programas. Os programas assim ficam subdivididos em dados e procedimentos. Essa abordagem possibilitava a criação de biblioteca de funções que possibilitava um bom nível de reuso, porém ainda não existia o conceito de herança, ou seja, não havia possibilidade de se criar procedimentos mais específicos a partir de outros mais genéricos. Além disso, não havia uma proteção sobre os dados e procedimentos dos programas. Assim um programador mal intencionado podia alterar essas informações comprometendo a qualidade dos programas.

Na tentativa de melhorar as deficiências apresentadas pela programação orientada a procedimentos, surge a programação modular cuja estrutura dividia os programas em módulos combinado os dados e os procedimentos dos programas. Essa abordagem resolvia parte do problema, porém ainda havia falhas no reuso de código e no encapsulamento dos dados.

A programação Orientada a Objetos vem como alternativa para solução desses problemas, promovendo diversos benefícios. Dentre os quais podemos citar: O reuso de código, a modularização e a simplificação de programas e ainda a redução dos custos de manutenção dos programas produzidos seguindo esse paradigma.

Como podemos concluir cada evolução na forma de se programar computadores não surge por acaso. Atualmente busca-se uma forma de se programar computadores de forma mais conceitual, ou seja, onde o programador apenas diz o que quer que o programa faça e a linguagem ou tecnologia de programação se encarrega “do como” atender ao pedido do programador. Parece-me que a OMG patrocina uma iniciativa desse tipo. Seu nome é MDA (Model-driven architecture). Eu ainda não estudei o assunto, mas quem se antecipa sai na frente.

Bom pessoal é isso aí.

Organizando as coisas e acelerando o processo.

Bom, se você seguiu algum dos caminhos citados no post anterior, mais especificamente o caminho do desenvolvimento de sistemas, já deve estar fazendo alguma coisa em relação a programação de computadores.

Você decidiu se dedicar a área de desenvolvimento de sistemas. Implementou um monte de algoritmos. Experimentou na prática uma série de técnicas de programação e com certeza chegou a uma conclusão de que apesar da evolução das linguagens de programação, programar é algo que demanda bastante tempo e esforço.

Tempo para escrever o código fonte dos programas, para testar e muito tempo para manter os sistemas que já foram desenvolvidos.

Enquanto isso acontece, seus clientes querem melhorias nos programas já desenvolvidos e novos clientes surgem com prazos apertadíssimos para o desenvolvimento de novos sistemas, com custos cada vez menores, cuja qualidade é essencial e onde há poucos recursos disponíveis.

Hoje o mercado de software demanda programas cada vez mais sofisticados, com prazos de entrega cada vez mais apertados. O cliente quer um produto de software de alta qualidade, baixo custo e tempo de entrega pequeno. Cabe aqui a seguinte pergunta: como chegar a uma equação utilizando essas grandezas inversamente proporcionais?

O primeiro passo dado nesse sentido foi o de incrementar o processo de manufatura de software. Não foi a toa que houve uma evolução nas técnicas de programação de computadores. Essa evolução surgiu da necessidade de acelerar o processo de desenvolvimento, promovendo o reuso de código, visando a facilidade de manutenção, sem que os produtos de software produzidos perdessem qualidade.

Nesse contexto, surgem a programação estruturada, a programação baseada em eventos, programação Orientada a Objetos, a programação orientada a aspectos e por aí vai.

Seguindo esta linha, surge também os designs patterns, que nada mais são do que nomes dados as técnicas conhecidas no mercado e que as empresas de software adotam para organizar os códigos-fonte que constituem os sistemas desenvolvidos por essas empresas.

As fábricas de software tiveram que adequar seus métodos de produção por conta das exigências de mercado citadas acima e para isso utilizaram as boas práticas de produção de software.

Além disso, as empresas de software criaram ou adotaram metodologias para a condução das atividades de desenvolvimento. A palavra metodologia deriva da palavra método e podemos definir método como sendo um conjunto de tarefas ou atividades que são necessárias para a conclusão de algum serviço ou objetivo.

Modelos de ciclos de vida como o modelo em cascata, espiral entre outros são criados de modo a nortear o processo de desenvolvimento de software.

Na área de desenvolvimento de sistemas existem duas metodologias que se destacam no mercado: O RUP (Rational Unified Process) e o XP (Extreme program). Logicamente, uma empresa pode desenvolver uma metodologia ou processo de desenvolvimento de software próprio, porém uma grande quantidade de empresas de software adota metodologias já experimentadas no mercado ou criam processos baseados nessas metodologias. Neste âmbito, não podemos deixar de mencionar o CMMI e o MPS BR que certificações centradas na qualidade e na melhoria de processos de desenvolvimento.

Enfim, o lema é encontrar meios de organizar o processo.

Que caminhos seguir

No último post falei um pouco sobre possíveis carreiras a serem seguidas na área de TI. A tônica deste post é qual caminho seguir, em que segmento investir nessa área.Acho que essa é uma resposta difícil de responder, pois quando uma pessoa escolhe uma profissão pode levar em consideração uma série de quesitos para apoiar sua decisão como oportunidade, custo benefício, grana ou o gosto natural por alguma atividade.

No início de uma graduação somos bombardeados por uma avalanche de informações. Acredito que essa situação visa justamente a tomada de decisão por parte do estudante no sentido de fazer uma escolha.No meu caso o quesito levado em consideração foi o da oportunidade. Tive um professor de programação que me apontou um caminho que até hoje em dia possui grande demanda e conseqüentemente apresenta muitas oportunidades - O desenvolvimento de sistemas.

Caminho escolhido! Qual o próximo passo? O que fazer para se tornar um analista desenvolvedor de sistemas? O que aprender? As respostas a essas perguntas me surpreenderam e podem assustar a qualquer aspirante ao cargo em questão.

Por conta do surgimento de novas tecnologias a cada dia, pode-se afirmar que hoje um bom programador é aquele cara que entende de tudo um pouco, pois os programas desenvolvidos por este profissional com certeza precisaram interagir com essas tecnologias. Por exemplo, vamos supor que uma empresa solicite a você o desenvolvimento de um sistema de controle de entrada e saída desta empresa e que as informações manipuladas por esse programa devam estar armazenadas em um banco de dados. O mínimo que se espera desse profissional é que ele conheça a linguagem de programação a ser utilizada para o desenvolvimento desse sistema e que o profissional saiba como manipular os dados do banco de dados em questão.

Vamos supor ainda que essa empresa possua uma matriz e diversas filiais espalhadas pelos quatro cantos do mundo de modo que o sistema tem que ser desenvolvido de forma distribuída. Além do conhecimento de programação e banco de dados, o programador agora deverá entender um pouco de redes. Afinal de contas, como os computadores espalhados pelos diversos endereços dessa empresa se interligariam na ausência ou na presença desta rede?

Começou a sentir na pele o drama de ter que se decidir que caminho seguir?É meu amigo! A decisão não é fácil.

Conheço gente que atua bem em qualquer um dos desafios apontados no post anterior. Esses são os profissionais que considero “cabeçudos”, ou que nasceram com um dom natural para o negócio.

Para mim foi uma questão de predisposição. Eu até esse momento não tinha sequer noção do que essas maquininhas de calcular avantajadas seriam capazes de realizar.Como não era cabeção resolvi seguir o conselho do Virgilio (o professor de programação mencionado neste post alguns parágrafos acima).

Agora se você quiser seguir o mesmo caminho que eu, leia as dez dicas que eu escrevo abaixo:

Primeiro passo: Aprenda lógica de programação. É importante memorizar aquela tabelinha verdade que os professores anotam no quadro ( V & V = V; V & F= F e por aí vai). Ela com certeza será muito utilizada nas estruturas de condição e repetição presentes em um programa.

Segundo passo: Adote um linguagem de programação para aplicar na prática o que foi aprendido nas aulas de lógica de programação. Eu, a época em que estava aprendendo lógica, decidi utilizar a linguagem javascript, pois a mesma não necessitava de nenhuma IDE (ferramenta utilizada para auxiliar o programador no desenvolvimento de sistemas). Com o bloco de notas do Windows, se consegue escrever os programas feitos em javascript.

Terceiro passo: Aprenda a manipular as informações constantes em um Banco de dados. Hoje em dia, a maioria dos SGBD ( sistemas gerenciadores de banco de dados) fala a linguagem SQL. Portanto pelos menos um pouco de SQL o programador deve saber. Inserir, alterar, consultar e excluir registros presentes em um banco de dados é essencial.

Quarto passo: Não basta saber lógica. É importante que o programado aprenda as técnicas já consagradas de programação. Existem uma série de algoritmos que mostram como ordenar ou estruturar dados (procure "bublesort" no Google que você vai entender do que estou falando).

Quinto passo: uma das qualidades de um bom profissional de desenvolvimento de sistemas deve aprender a abstrair, ou seja, separar do resto do mundo o que realmente interessa ao cliente ou a empresa que demanda um sistema.

Sexto passo: Aprenda a entender os diagramas utilzados na relação entre os interessados no sistema. A UML é a linguagem utilizada pela maioria das empresas no mercado. Seguir esse padrão sem dúvida irá diferenciá-lo dos demais profissionais que atuam na área de desenvolvimento de sistemas.

Sétimo passo: Consulte os exemplos de algoritmos constantes nos diversos fóruns de discurssão sobre o assunto espalhados pela Internet. Tente entender a técnica ou lógica utilizada nesses códigos. Com o tempo você notará que algumas soluções poderão ser utilizadas em diversos sistemas desenvolvidos pelo programador ao longo de sua trajetória profissional.Oitavo passo: Não tem pra onde correr. Fiquem alerta as tecnologias que surgem a cada dia. XML, AJAX, Web services. Tenha a certeza que uma hora, um sistema desenvolvido por você terá que interagir ou fazer uso de uma dessas tecnologias.

Nôno passo: Uma hora você irá perceber que a maioria dos sistemas que acessam banco de dados fará a mesma coisa, ou seja, incluirá, alterará, excluirá e consultará dados constantes de um banco de dados com o objetivo de produzir informação.

Décimo passo: Todo programa deve realizar algum tipo de processamento. Assim, alguém ou algo fornece argumentos para o programa (entrada). Esses dados são processados (processo) pelo programa e gera algum tipo de resultado (saída).

Décimo primeiro passo: Um analista deve ter o dom da abstração, ou seja, o analista deve possuir a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades existentes no domínio do sistema de software.

E por último eu diria o seguinte: sem dedicação e persistência não há santo que ajude a alguém a conquistar um objetivo. Lembre-se você está traçando o seu caminho profissional e como tal essa trajetória deve ser tratada com seriedade.

Espero ter ajudado!

Saudações a todos.