Conceitos de Pressman

Conforme Pressman, a Engenharia de Software (ES) é uma tecnologia em 3 camadas: processos, métodos e ferramentas. E a base de todas essas camadas é o foco na qualidade do software desenvolvido.

1. Processos: constituem um elo de ligação que mantém juntos os métodos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software de compuitador.É o alicerce da engenharia de software.
   
2. Métodos: proporciona os detalhes de "como fazer" para construir o software;
3. Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos métodos (ferramentas CASE combinan software, hardware e um banco de dados).
   

Ainda segundo Pressman, o trabalho associado à engenharia de software pode ser categorizado em 3 fases genérias, independentemente da área de aplicação, do tamanho do projeto ou de sua complexidade: 

1. definição;
2. desenvolvimento;
3. manutenção.
   

O teste de software,sob o ponto de vista dos métodos convencionais da ES, é, na realidade, uma séria de quatro passos, implementados na seguinte ordem: unidade, integração, validação e sistema.

Gerência de projetos: métricas de software

O gerenciamento de projetos de software representa a primeira camada do processo de engenharia de software. O gerenciamento de projetos compreende atividades que envolvem medição, estimativa, análise de erros, programação de atividades, monitoração e controle.

A medição prosibilita que gerentes e profissionais entendam melhor o processo de engenharia de software e o produto (software) que ele produz. Usando medidas diretas e indiretas, as métricas de produtividade e qualidade podem ser definidas.

Métricas orientadas tanto ao tamanho como à função são usadas em toda a indústria de software. As métricas orientadas ao tamanho fazem uso das linhas de código como fator normalizante para outras medidas, tais como as medidas de pessoas-mês ou defeitos. O ponto-por-função deriva de medidas do domínio da informação e da avaliação subjetiva da complexidade do problema.

Métricas de qualidade de software, como a métrica de produtividade, concentram-se tanto no processo como no produto. Ao desenvolver e analisar uma linha básica para a qualidade, uma organização pode tomar providências para corrigir aquelas áreas do processo de engenharia de software que são a causa principal dos defeitos do software. Neste capítulo, quatro métricas da qualidade - corretitude, manutenibilidade, integridade e usabilidade - foram discutidas.

A medição resulta em mudança cultural. A coleta de dados, computação das métricas e avaliação dos dados são os três passos que devem ser implementados para se começar um programa de métricas. Ao criar uma linha básica - um banco de dados contendo medições do processo e do produto -, os engenheiros de software e seus gerentes podem obter uma melhor visão do trabalho que realizam e do produto que produzem.

Administração de projetos: estimativas

O planejador do projeto de software deve estimar três coisas antes que um projeto se inicie: quanto tempo ele durará, quanto esforço será exigido e quantas pessoas estarão envolvidas. Além disso, o planejador deve prever os recursos (hardware e software) necessários e os riscos envolvidos.

A declaração do escopo ajuda o planejador a desenvolver estimativas usando uma ou mais das seguintes técnicas: decomposição, modelagem empírica e ferramentas automatizadas. As técnicas de decomposição exigem um delineamento das principais funções do software, seguidas ou do número de LOC ou FP ou do número de pessoas-mês exigido para se implementar cada função. As técnicas empíricas usam expressões empiricamente derivadas para o esforço e o tempo a fim de prognosticar essas quantidades para o projeto. As ferramentas automatizadas implementam um modelo empírico específico.

Estimativas de projeto precisas geralmente fazem uso de pelo menos duas das três técnicas adotadas anteriormente. Ao comparar e ajustar as estimativas derivadas usando direfentes técnicas, o planejador tem maior probabilidade de derivar uma estimativa que se aproxime bastante da realidade. As estimativas de projetos de software jamais poderão ser uma ciência exata, mas uma combinação de bons dados históricos com técnicas sistemáticas pode melhorar a precisão da estimativa.

Fontes: 

http://qtmarinha.blogspot.com/2008/08/engenharia-de-software.html

http://pt.wikipedia.org/wiki/Engenharia_de_software

UML

Fonte: Eduardo Bauer Londero, Instituto de Informática da UFRGS

Introdução:

UML, ou Unified Modeling Language é a última buzz-word a chegar por estas plagas. O seu charme é a promessa de ser a última e definitiva metodologia de modelagem de sistemas. Outro apelo, é integrar todas as demais expressões (métodos empíricos todos eles) que atestam sua origem "nobre": orientação a objeto, padrões, GRASP. Sendo posterior a todas elas, promete ser uma maneira de se atualizar sobre todas elas de uma só vez.

Muitos dos exemplos, foram retirados de telas criadas com Rational Rose 98, uma ferramenta CASE da Rational. Convém mencionar que esta ferramenta não implementa inteiramente o UML, havendo diferenças de notação. Sempre que for o caso, a origem da imagem será indicada.

Perto do final do semestre descobrimos em [HAR97] referência a outra ferramenta CASE, a SA/Object, disponível em www.popkin.com, mas não conseguimos avalia-la ainda.

UML pretende:

1- Modelar sistemas, sejam eles empresas ou softwares, usando conceitos de orientação a objeto.
2- Estabelecer um acoplamento explícito tanto entre artefatos conceituais como executaveis (reais).
3- Encaminhar as questões de escala (num intendi...) inerentes em sistemas complexos e/ou de missão crítica.
4- Criar uma linguagem de modelagem usável por ambos: humanos e máquinas.

Método é uma maneira explícita de estruturar ações e pensamentos. Um método diz o que fazer, como, quando e porque. Métodos contém modelos e estes modelos são usados para descrever algo e comunicar os resultados do uso do método.
Um modelo é descrito em termos de uma linguagem de modelagem. Uma linguagem é composta por símbolos que compõem uma notação e regras sobre seu uso. Estas regras correspondem a três planos de entendimento:

• intaxe - Diz como devem parecer e como devem ser combinados os símbolos utilizados
• Semântica - Diz o que cada símbolo significa. São (a semântica e a sintaxe) referidos à própria relação entre os símbolos (regras internas )
• Pragmática - Define a intenção dos símbolos, de modo que o propósito do modelo é expresso e torna-se inteligível para outras pessoas. É uma referência externa/cultural à relação representada, é funcional e finalística

---

Fases do Desenvovimento do Sistema:1) Análise dos Requisitos:

UML se vale de use cases; diagramas para capturar o requisitos do usuário. Através dos use cases, atores externos são modelados em suas interações com o sistema. Semelhante ao DFD contextual, mas usando bonequinhos de palitos para representar os atores/agentes externos. Não é tão simples assim, mas a semelhança é óbvia.

2) Análise:

Nesta fase nos preocupamos com as abstrações primárias (classes e objetos) e mecanismos no domínio do problema. As classes são identificadas e representadas no diagrama de classes. Também são representadas as relações e colaborações entre as classes, de modo que as funcionalidades descritas nos use cases sejam alcançadas. Também se vale dos diagramas dinâmicos (estado, seqüência, colaboração e de atividades).
Na análise, somente classe do domínio do problema são modeladas. Aquelas que definem detalhes e soluções da implementação de software (interface, comunicação com banco de dados, concorrência, etc..) ficam para outra fase.

3) Projeto:
Na fase de projeto (design), o resultado da análise é expandido para uma solução técnica. Novas classes são acrescentadas para prover uma infraestrutura técnica: interface, manipulação de dados em um banco de dados, salvamento de arquivos, comunicação com outros sistemas e dispositivos. Nesta etapa as classes da análise são "embutidas" (embedded) nesta infraestrutura técnica, sendo possível alterar ambas independentemente.
O resultado é uma descrição detalhada para a fase seguinte, de programação.

4) Implementação:
As classes são convertidas para código real em uma linguagem OO (procedural não é recomendado).

5) Teste:
Idêntico a qualquer outro método de modelagem. Dividida em testes de unidades, testes de integração, teste de sistema e testes de aceitação.

---

Visões e Diagramas
São cinco visões (ou vistas, tradução para view) e nove diagramas. Visões

Visão dos Uses Cases	É central no UML, e define as funcionalidades do sistema e seu conteúdo define o desenvolvimento subseqënte das outras visões. É usado para validar o sistema junto ao usuário (é assim que você quer/queria ?). Usa o diagrama de use case.
Visão Lógica	Descreve como a funcionalidade do sistema é alcançada. Em contraste com os use cases, a visão lógica vê o sistema internamente. descre tanto a estrutura estática como a colaboração dinâmica que ocorre quando os objetos se comunicam para prover alguma função. Usa para a estrutura estática os diagramas de classes e objetos. Para a modelagem dinâmica usa os diagramas dinâmicos: estado, colaboração, seqüência e atividade.
Visão dos Componentes	É uma descrição dos módulos da implementação com suas estruturas e dependências. Consiste no diagrama de componentes e outros diagramas de caráter administrativo, tasi como relatório de progresso.
Visão Concorrente	Lida com a divisão do sistema em processos e processadores. É um aspecto não-funcional do sistema, que visa desempenho, eficiencia no uso dos recursos e manejo de eventos de eventos assíncronos do ambiente.
Visão do Desenvolvimento	Mostra o desenvolvimento físico do sistema, com computadores, sites, nós e como eles se conectam. Esta visão inclui um mapeamento que descreve como os componentes da visão lógica tornam-se componentes reais, e qual a sua localização física subseqüente.

Diagramas

Em amarelo, os diagramas estáticos. Em verde os dinãmicos.

Diagrama de Use Cases	Mostra atores externos e suas conecções com os use cases do sistema. Cada use case é a descrição de uma funcionalidade (um uso específico do sistema) que o sistema oferece.
Diagrama de Classes	Um diagrama de classes mostra a estrutura estática das classes. As classes são "as coisas" com as quais o sistema lida. São representadas por retângulos, com o nome da classe em negrito. Classes podem se relacionar umas com as outras de várias maneiras: associação, dependência, especialização ou empacotamento
Diagrama de Objetos	O diagrama de objetos se parece muito com o diagrama de classes, apenas mostra as classes instanciadas como objetos, como um snapshot possível da execução do sistema. A mesma notação é adotada, apenas o nome do objeto é escrito sublinhado. Diagrama de objetos é utilizado em diagramas de colaboração
Diagrama de Estados verdes:diagramas dinâmicos	O diagrama de estados é tipicamente um complemento do diagrama de classes. Mostra todos os possíveis estados de uma classe e quais eventos causam a mudança de estados. Mudanças de estado são chamadas de transições Ele é desenhado apenas para aquelas classes que tem um número bem definido de estados e cujo comportamento é mudado pelas transições. Pode também ser desenhado para o sistema inteiro.
Diagrama de Seqüência	O diagrama de seqüência mostra uma colaboração dinâmica entre objetos. O aspecto mais importante é mostrar uma seqüência de mensagens trocadas entre os objetos. Objetos são descritos como linhas verticais e mensagens como linhas horizontais entre os objetos. A mensagen bifuracada (uma origem, vários destinos aparece em [ERI97], mas o Rose98 não foi capaz de representá-la.
Diagrama de Colaboração	Mostra uma colaboração dinâmica, exatamente como o diagrama de seqüência. Freqüentemente é uma alternativa ao diagrama de seqüência, quando se deseja mostrar os objetos e seus relacionamentos (chamado de contexto). Se o tempo é mais importante, escolhe-se o de seqüencia e caso o contexto seja mais importante, escolha o de colaboração.
Diagrama de Atividades	Mostra uma seqüência de atividades como um grafo, o que permite representar decisões (bifurcações) graficamente, bem como estado inicial e final.
Diagrama de Componente	Traz uma visão interna da estrutura física do código, em termos de componentes. Um componente pode ser um código fonte, um componente binário ou um executável. É um mapeamento entre a visão lógica e a visão de componentes. Dependências entre componentes são mostradas, tornando fácil analizar alterações.
Diagrama de Desenvolvimento/Entrega	Mostra a arquitetura física - hardware e software no sistema. Representa-se os computadores e dispositivos reais e as conecções entre eles.

---

Elementos de Modelo

São os conceitos (o vocabulário) utilizados nos diagramas. Um elemento de modelo tem uma representação gráfica que o representa nos diagramas.
São exemplos de elementos: classe, objeto, estado, caso de uso, nó, interface, package, nota, componentes.
Também os relacionamentos são considerados elementos: associação, generalização, dependência e agregação.

---

Mecanismos GeraisAdornos:
Detalhes gráficos (chamados em inglês de adornos) podem ser acrescentados aos elementos dos diagramas, de modo a acrescentar significado semântico. Por exemplo, se um elemento representa um tipo, usa-se negrito, se representa um objeto aparece sublinhado. No caso de um nodo, no diagrama de desenvolvimento, pode-se escreve "impressora" ou "HP 5J - Sala dos professores".

Notas:
Uma nota pode ser acrescentada a qualquer diagrama, para lembrar de algo que a linguagem não possa representar. Como a UML e todas as suas predecessoras são abstrações limitadas, muitos detalhes do problema ficam de fora e precisam encontrar seu caminho dentro do projeto acomodadas, por exemplo, em notas acompanhado os diagramas.

Especificações:
Os elementos de modelo têem propriedades que guardam valores sobre os elementos. Uma propriedade é definida por um valor etiquetado . Existe um certo número de propriedades pré-especificadas: documentação, responsabilidade, persistencia e concorrência.
Tipicamente, é necessário acrescentar algum texto descritivo, existindo uma janela para este fim para cada elemento de modelo no Rose98.

---

UML Extendida

UML pode ser extendida para cumprir funções específicas. Em [ERI97] encontramos três exemplos destas extensões, que enriquecem a notação do Rose98:

Esteriótipos: é um mecanismo de extensão que traz uma semântica. Baseia-s em todos os elementos básicos (classe, nós, componentes e notas), bem como nos relacionamentos (associação, generalização e dependência).
É descrito colocando o seu nome entre << >> (referidos como guillemets, ou angle brackets), ou lhe atribuindo um ícone específico, como o do ator.

Valores etiquetados: elementos podem ter propriedades que contém pares de nomes-valores, com informação sobre eles. São valores marcados ou valores etiquetados. Qualquer informação pode ser acrescentada nestas etiquetas: informações administrativas, informações específicas do problema, dados para outras ferramentas.

Restrições: Um vínculo restritivo é uma limitação em um elemento, que resulta em limitação na sua associação. Por exemplo: a classe "grupo da terceira idade" relaciona-se com a classe "pessoa", com a restrição de que {idade > 60} (ou 110, para moradores do Caúcaso), ou seja, somente pessoas com mais de 60 anos podem participar da associação (ou funcionários-gerentes, outro exemplo).

Testes de Software - 2

BSI03

O artigo trata da importância de Testes de Software no processo de desenvolvimento, e o quanto ele pode garantir que sistemas tenham seu nível de qualidade na entrega acrescido. Através dos testes é possível filtrar grande parte de erros muitas vezes simples e de fácil resolução que não foram descobertos pelos desenvolvedores e que se fossem para cliente poderiam causar um constrangimento ou mesmo quebra de contrato.

Muitas vezes ele é descartado por empresas pelo fato de custar muito caro ( em torno de 40% do tempo, segundo pesquisas em empresas que adotam a metodologia) e por ter seus objetivos mal compreendidos. Assim, pensar que os testes devem ser executados de maneiras apenas manuais e cansativas ou que os testes apenas irão demonstrar as funcionalidades implementadas no sistema são equívocos comuns que desencorajam a utilização desta fase tão importante do ciclo de desenvolvimento.

Existem muitos tipos de testes que podem ser aplicados em momentos diferentes do desenvolvimento e de formas diferentes. Alguns são realizados de maneiras automatizadas (geralmente em testes que devem ser executados com maior freqüência ou que exijam imparcialidade) evitando que, por exemplo, um usuário que já esteja acostumado com o sistema passe pelos erros sem notá-los, devido ao vício causado pela constante utilização, ou mesmo para evitar que isto se torne uma atividade enfadonha para quem tem que testar. A automatização é muito útil em testes de unidade ou de integração.

Testes de Softwares são comumente relacionados a cores, onde os testes de caixa-branca representam a parte de testes responsáveis por garantir que todas as partes do código fonte estão funcionais e sem erros. Testes de caixa-preta preocupam-se apenas com os requisitos do software, verificando se estes estão sendo atendidos. E por fim também existem os testes de caixa-cinza que é a mesclagem entre os testes de caixa branca e preta.

Para que a execução dos testes seja feita de forma padronizada, existe uma área que deve ficar responsável apenas por isto. Nesta área encontram-se profissionais como testador, que executa o testes, analistas responsáveis pela montagem de ambiente e pela definição das condições dos testes, além do engenheiro que provê as soluções e o gerente que é o responsável por todo o processo.

Com isto percebe-se que testar software é algo bastante abrangente, mas que não deve ser utilizado sem a análise do projeto como um todo. Devido ao alto custo na execução de testes e a grande variedade de tipos é fundamental que se perceba quais testes realmente são necessários para o sistema e executá-los. Quando mal interpretados, testes podem elevar o custo/tempo de um projeto e não trazer o objetivo esperado, já que de nada adianta eu ter um teste de integração se meu sistema não é em módulos, por exemplo.

Testar deve ser premissa em desenvolvimento de software e isto é uma questão de cultura que deve ser adotada pela equipe como um todo. Eleger profissionais responsáveis por ferramentas ou testes mais pesados é excelente, mas se o programador não faz a parte dele fazendo um teste unitário ou outro teste mais simples que seja (mesmo manual) e pensando que encontrar os bugs é responsabilidade do testador só fará com que exista uma transferência de responsabilidade sobre o software parecendo que se o sistema tem bug é “problema” do testador.

Quando existir cooperação entre todos da equipe e a visão de que o produto é da empresa, testar passará a ser sinônimo de garantir um bom trabalho e com certeza um aumento de qualidade no que será percebido no que for entregue ao cliente final. Testar deixará de ser atividade trivial e desgastante para ser rotineira e gerar bons resultados.

Testes de Software

ECP04

Os autores abordam um tema em seu artigo de especial destaque hoje entre empresas de desenvolvimento, o setor de testes de software. Descrevem os principais pontos do conjunto estendendo-se da sua importância e planejamento até métodos e suas fases.

Introduzem o contexto abordando atributos da ISO 9126: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade, que estão relacionados à qualidade de aplicações e podem ser alcançadas com o uso de testes que verifiquem estas condições.

Num segundo ponto, a estruturação e planejamento de testes, demonstrando questões que são apresentadas nesta etapa como o que, como, quem efetuará e quando efetuará os testes. Questões estas que são levantadas e propiciam o planejamento, segundo os autores.

Teste de caixa Branca/Preta – Estes dois métodos de testes acabam sendo descritos, sendo o caixa branca como um teste que avalia a parte interna, ou seja, o código e suas partes – decisões, fluxos, ciclos e caminhos lógicos; e o caixa preta avaliando conforme as entradas, as saídas que geram, sendo apresentados técnicas como Teste de Performance, Teste de Usabilidade, Teste de Carga, Teste de Stress, Teste de Confiabilidade e Teste de Recuperação. Em cima do teste de caixa branca, uma ferramenta profissional é apresentada: o JUnit, utilizado em testes de sistemas orientados a objeto, específico em Java.

O artigo trata de uma forma clara e rápida sobre as fases de teste, informando para o leitor os nove tipos (unidade, integração, sistema, aceitação, operação, regressão, alpha, beta e gama), descreve também o significado de cada um e sua importância como também é tratado o tema Release candidates, nesse caso dá-se um exemplo do que acontece com uma empresa de grande porte como a Microsoft.

Testes automatizados – de forma macro são apresentados o quê e o porquê dos testes automatizados, demonstrando que erros e más práticas de programação podem ser corrigidos facilmente. Além de mostrar sua importância como auxilio a incapacidade humana de chegar à perfeição, tanto na programação, quanto na execução de testes.

Embora sendo um artigo breve, os autores foram específicos, quanto à importância dos testes de software e uma observação de que os testes podem ajudar na implementação, e mesmo que seja uma alteração mínima no tempo de execução, isso pode ser de muita importância para o uso ou não da ferramenta.

Alguns pontos devem ser levados em consideração, como a citação de alguns termos sem a devida descrição, obrigando o leitor a procurar alguns conceitos básicos como o que é um arquiteto de testes, por exemplo. O título ficou muito abrangente dando a possibilidade infinita de conhecimento, olhando este ponto tem-se a impressão de que falta conteúdo, o que na verdade falta um melhor foco do título.

Projetos de sistemas de tempo real

BSI07

Um projeto de sistema de tempo real é bem peculiar por seus requisitos e metodologias de desenvolvimento e teste. Está inteiramente ligado ao tempo de execução do processo, pois este tem que ser concluído no menor tempo possível ou no exato momento definido.

Antigamente poucas empresas desenvolviam este tipo de projeto, a maioria dessas hoje estão firmes no mercado, pois a necessidade de aplicações de tempo real cresce até mesmo hoje em dia. Para se desenvolver uma aplicação dessas antigamente era algo muito complexo.

O grau de complexidade de um projeto reflete em seu custo, por isso projeto de sistemas de tempo real são muito caros, principalmente por seus rigorosos testes de requisitos.

O modelo DARTS auxilia a definir a ordem do desenvolvimento de um projeto de tempo real, isso em quatro passos:

1. Criação dos diagramas de fluxo de dados, DFD;
2. Dicionário de dados;
3. Definição de tarefas;
4. Definição de interfaces entre funções.

Entendemos que o desenvolvimento de projetos de sistemas de tempo real é uma atividade complexa, mas rentável e que com muita disciplina, embasamento técnico e testes pode-se ter um ótimo resultado.

Design Patterns

BSI05

O trabalho trata de vários Design Patterns, e os define como "soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto nada mais é do que uma solução para esse determinado problema". No artigo foram citados vários Design Patterns, são eles: Singleton, Facade, Iterator, e MVC.

É feita a definição onde separa estes vários design patterns em duas categorias. Os do tipo do tipo GoF, ou Gang of Four que dividem os design patterns em 3 categorias: criação, estrutural e comportamentais. E os do tipo Grasp, ou "General Responsibility Assignment Software Patterns" que conforme afirma a equipe existem diversos padrões, porém eles abordaram somente um Design Patter Grasp Controller.

Iniciando as explicações de Design Patterns, o primeiro a ser apresentado foi o Sigleton, este serve para garantir que somente uma instânsia de uma classe exista mantendo um único ponto global de acesso ao seu objeto. A equipe defende que este tipo de prática não sobrecarrega a memória do sistema e faz a distinção entre o singleton contra os métodos estáticos e contra injeção de dependência. Onde o primeiro não é aconselhado o uso do singleton para essa situação e destaca que seu uso abre mão de algumas vantagens como a perda do polimorfismo. Porém não há nenhum exemplo de código que demonstre a situação e não há um levantamento das vantagens e desvantagens do uso do Singleton em relação a outros design patterns.

Em seguida é comentado sobre o FACADE, onde cita que o facade pode ser considerado um encapsulador de classes, onde o programa fáz o acesso a elas atravéz do próprio FACADE facilitando a arquitetura do projeto como um todo. Esclaresce que o FACADE é uma interface simplificada para uma classe mais complexa, e que na verdade não passa de uma organização da classe ordenando os seus métodos por funcionalidades ou outros critérios.

O último design patterns citado do tipo GoF é citado o ITERATOR. Ele é usado para que iteradores utilizados para acessar os elementos de um conjunto de objetos, não exponham a sua arquitetura nem a forma como os objetos são iterados. Porém não há uma definição de por que isso traria alguma vantagem ao desenvolvimento, assim não ficando claro o objetivo do ITERATOR.

Por fim define o MVC em Model, View e Controller e explica cada uma destas camadas. Citando que o Model contém os dados das aplicações e as regras de negócio que se associam a ela. View como a camada que o usuário interage diretamente. E por fim o Controller como que responde a eventos normalmente disparados pelo usuário atravéz de uma View.

Em geral o artigo apresenta vários Design Patterns, mas não mostra exemplos de código nem as aplicações deles em software conhecidos. Desta forma não fica claro o grau de efetividade na adoção destes como ferramenta de trabalho. Porém ele é bem útil para mostrar a existência de diversos design patters, assim como a sua divisão entre os dois tipos direferentes de padrões GoF e Grasp os quais não conheciamos.

Ciclo de vida do Software

ECP01

Esse artigo mostra a importância dos modelos de ciclo de vida para o desenvolvimento de um software. Nesse artigo são destacados os modelos em cascata, de prototipação, espiral e interativo.

No modelos em cascata, uma fase só começa quando a anterior terminou, não podendo voltar atrás.

Segundo a proposta inicial de Winston Royce (Royce, 1970), considerado o inventor do modelo em cascata, este modelo se caracteriza por possuir uma tendência na progressão seqüencial entre uma fase de desenvolvimento e a seguinte.

No modelo de prototipação, são desenvolvidos protótipos para que o usuário final do sistema possa interagir com o software e assim ele pode dizer se era isso o que ele esperava. De acordo com Jalote a idéia básica deste modelo é que ao invés de manter inalterado os requisitos durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos.

No modelo espiral, é uma mistura do modelo em cascata com o de prototipação, porque como o modelo em cascata uma fase só começa depois da anterior ter terminado e como o de prototipação cada ciclo é gerado um protótipo. Segundo o site macoratti, Uma maneira simplista de analisar este modelo é considerá-lo como um modelo cascata onde cada fase é precedida por uma análise de risco e sua execução é feita evolucionariamente (ou incrementalmente).

No modelo incremental, são geradas versões, onde a próxima versão será criada em cima dos riscos encontrados na versão anterior. Segundo o site mundooo, um processo de desenvolvimento segundo esse modelo divide o desenvolvimento de software em iterações. Em cada iteração, são realizadas as atividades de análise, projeto, implementação e testes para uma parte do sistema.

Concordamos com os autores desse artigo, que concluiram que cada modelo tem sua vantagem e que deve ser escolhido conforme a situação de utilização e gostariamos de destacar que o modelo em cascata possui vantagens em se dedicar a cada fase individualmente o que posivelmente reduz erros, o modelo de prototipagem tem vantagem de interagir mais com o cliente, o que divide a responsabilidade do desenvolvedor com o cliente, o modelo em espiral mescla as vantagens dos modelos em cascata e de prototipação e o modelo incrementel tem a vantagem de realizar as funcionalidades mais importantes primeiro, o que para nós faz o modelo em espiral o mais interessante, porém tudo depende da aplicação.

MDA - Model Driving Architecture

ECP02

Os autores se preocupam no artigo em deixar claras as definições de MDA (Model Driving Architecture) e os padrões OMG (Object Mamagement Group) que a suportam, focando UML(Unified Modeling Language). MDA dá importância à modelagem no processo de desenvolvimento do software, baseado em um modelo abstrato do sistema, modelos mais concretos são criados seguindo processos de refinamento dos modelos empregados.

Nos quatro tipos de modelos: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model) e ISM (Implementation Specific Model) faltou uma comparação de modelos, destacando as vantagens de cada um. As idéias básicas com relação à natureza abstrata de um modelo: classificação do modelo, independência de plataforma e transformação do modelo e refinamento foram abordadas de forma clara mostrando o potencial do uso do MDA, mas o artigo peca por não ter exemplos práticos e estudos de caso. A finalização de maneira simples, contudo direta, lista as vantagens do uso da MDA.

O MDA é uma ótima ferramenta na resolução de problemas de integração através de especificações de interoperabilidade, tem papel fundamental não só na documentação como na implementação dos sistemas, auxiliando na redução de custos e prazos no desenvolvimento de aplicações.

A Aplicação da Engenharia de Software Sob Três Ambientes

BSI04

O artigo fala sobre diferentes formas para que o processo de desenvolvimento de software seja melhorado, enfatizando o estudo em três diferentes cenários e mostrando como a engenharia de software impacta positivamente, através da introdução de conceitos como fábrica de software e CMMI.

São explicados também os motivos que levam uma empresa a não utilizar a engenharia de software em seus procedimentos, na maioria dos casos ele é financeiro, pois os métodos que são utilizados geralmente só geram retorno a longo prazo. Mas a não implementação também pode ocorrer pela resistência a mudanças por parte dos funcionários

Devido ao grande avanço tecnológico, é de grande importância que as empresas de pequeno,médio e grande porte invistam em processo de Engenharia de Software , pois esta funciona como uma ferramenta de apoio ao desenvolvimento de software, pois a mesma se preocupa com todos os aspectos de produção de um software.

O processo de Engenharia de Software, deve ser implementado nas empresas independente de seu tamanho e estrutura, pois é preciso ter uma controle e uma seqüência de prioridade, independente de custo que se terá esta implantação, isso gerará para empresa uma qualidade de software tendo assim um destaque em sua produtividade.

O artigo não é muito claro no ponto em que se quer chegar com cada parte do texto, a forma de organização dos capítulos e assuntos mostrados dificulta o entendimento do real objetivo por trás da discução apresentada.Porém o artigo não deixa de ser uma boa fonte de pesquisa relacionada a melhora no processo de desenvolvimento.

Metodologia de Desenvolvimento Ágil

ECP05

As metodologias de desenvolvimento tradicionais são ineficientes, pois focam-se em burocracia ao invés dos resultados. Para que essas fossem bem sucedidas, deveriam focar-se nos resultados.

Com essa finalidade, em 2001, foi criado um novo modelo de desenvolvimento, e foi chamado de "Manifesto Ágil". As principais premissas da metodologia de desenvolvimento ágil são:

• Indivíduos e interação entre eles mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

Com isso, percebeu-se que os softwares desenvolvidos com essas novas metodologias tiveram maior aceitação tanto pelos clientes quanto pelas empresas desenvolvedoras, por haver uma maior agilidade na entrega do software e no processo de desenvolvimento do mesmo.

MVC e Django

BSI01

São duas ferramentas de alto nível para a área de desenvolvimento, são consideradas de alto nível e fácil manipulação do código fonte. Mas não muito difundidas pelas empresas por elas escolherem outras ferramentas a desenvolver suas aplicações.

A MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter, testar e atualizar sistemas múltiplos. É fácil incluir novos clientes, apenas incluindo seus visualizadores e controladores. É possível ter desenvolvimento em paralelo para o modelo, visualizador e controle, pois são independentes. Porém requer uma quantidade maior de tempo para modelar o sistema, necessita de pessoal capacitado e não é recomendável para pequenas aplicações.

De acordo com a descrição encontrada no site do Django Brasil, "Django é um framework web de alto nível escrito em Python que estimula o desenvolvimento rápido e limpo". Ele possibilita o desenvolvimento de sistemas de forma ágil, fazendo com que os programadores desenvolvam num curto espaço de tempo. Mas como é uma ferramenta não muito conhecida os programadores optam em desenvolver nas que estão mais difundidas no mercado.

Elas têm uma grande chance de se tornarem popular assim que empresas de grande porte adotarem ela no seu ambiente de desenvolvimento, tornando-as mais difundidas no mercado.

Aplicações cliente-servidor usando Delphi

ECP06

Conforme a apresentação dos alunos e o artigo em questão foi verificado que a plataforma Delphi se aplica a necessidade de comunicação cliente – servidor com vantagens resumidas anteriormente, porém, a linguagem não é uma das melhores utilizadas atualmente. Visto que, possuímos outras ferramentas com mesmas funcionalidades, até mesmo simplificadas e com mais aplicabilidade em várias plataformas, como por exemplo, para dispositivos móveis.

A versão do Delphi abordada no trabalho, por se tratar de um ambiente de desenvolvimento construído para suprir as necessidades da época, nos dias de hoje, possivelmente poderia ser substituído por tecnologias com maior aplicabilidade. No artigo relacionado foi dada ênfase a comunicação aplicação local – servidor, mas a maior tendência dos serviços web, não cabe ao contexto proposto. Apesar de que com a chegada do Delphi 7 integrando com a biblioteca IntraWeb aumentaria a gama de usabilidade da ferramenta em questão.

Em suma temos uma boa ferramenta para a construção de aplicações do gênero, porem com suas limitações.

Métodos de Desenvolvimento

BSI02

“Métodos de desenvolvimento” (IST, 2008, 10 páginas) dos estudantes Dayane da Silva Weinrich, Marco Aurelio Pontes, Rodrigo de Oliveira Cardoso apresenta um estudo sobre as ferramentas utilizadas para o desenvolvimento de software abordadas de forma sucinta e bastante clara para o entendimento do leitor.

Os autores procuraram deixar claro cada modelo de desenvolvimento apresentado e para isso fizeram uso de diagramas exemplificando cada processo.

O modelo em cascata apesar de dar a organização ao desenvolvimento, pois só permite o trabalho do próximo passo após a conclusão do atual, deixa a desejar no quesito de reestruturação do código. Caso tenha-se necessidade de acrescentar algo a um processo já feito, não lhe é permitido.

Com o modelo interativo os autores demonstram que o software é desenvolvido em partes, e testado pelos usuários conforme os códigos vão ficando prontos. Apesar de mostrar a facilidade de controle isso pode demandar muito tempo de desenvolvimento.

No modelo ágil o artigo comenta que é um método de desenvolvimento rápido e comenta apenas que perde em planejamento esquecendo de comentar sobre a qualidade do software que deixa muito a desejar.

Modelo formal é o modelo que se prepara melhor antes do desenvolvimento, evitando ao máximo possíveis erros de programação que geram custo elevado no inicio, mas compensa ao final do projeto.

Modelo aspiral abordado no artigo ficou muito vago, pois não ficou claro as forma como desenvolver.

Rup é um modelo completo que se utiliza de ferramentas para auxiliar no desenvolvimento.

E Cleanroom que é o método mais caro, mas com o software mais correto possível ao seu final.

Os autores tentam passar nesse artigo, uma idéia de modelos de desenvolvimento onde apresentam um a um cada ferramenta. Eles abordam muito bem os conceitos e definições de cada metodologia demonstrando inclusive diagramas do processo, porém esse artigo não deixa claro exemplos de utilização dos modelos, o que facilitaria muito o entendimento do desenvolvedor.

Um ponto que deixa dúvidas é sobre as fontes que os autores tomaram como base, sendo um site de colaboração publica, pode ocorrer informações imprecisas.

Apesar de tudo, o artigo contempla muita informação sobre as ferramentas e ajuda na decisão de qual caminho seguir no planejamento e desenvolvimento de software.

Engenharia de Componentes aplicada no Framework TOTVS Joinville

ECP03

A engenharia de software baseada em componentes é um assunto importante e um método de desenvolvimento que é robusto e de fácil utilização. Teremos aqui exposto o caso TOTVS na uitilização da ESBC (Engenharia de Software Baseada em Componentes).

Um componente nada mais é do que uma parte modular, possível de ser implantada e facilmente substituída de um sistema que encapsula a implementação e exibe o conjunto de interfaces. Com esta definição de componente resta ainda entender o que é a ESBC.

ESBC (Engenharia de Software Baseada em Componentes) tem uma simples e fácil explicação que foi explanada por Pressman em 2006: “É um processo que enfatiza o projeto e a construção de sistemas baseados em computador usando componentes de software reusáveis”

A empresa TOTVS Joinville vem fazendo uso da ESBC para melhorar o seu desenvolvimento de software. Eles utilizam um framework que contém as principais e mais importantes partes do software que já foram desenvolvidas para que a partir desse framework seja feita a reutilização dos componentes necessários para novos aplicativos, novas implementações, atualizações, correções, etc.

Este tipo de trabalho torna o desenvolvimento mais ágil sendo que antes de novos desenvolvimentos o framework é revisto com o intuito de melhorar o mesmo e verificar se as inovações necessárias já não estão presentes no framework.

A grande vantagem deste modelo é a confiabilidade dos componentes, pois existe uma grande carga de testes a cada reutilização. Podemos citar ainda menos gastos, maior agilidade, menores riscos, dentre outras tantas vantagens nesta abordagem.

Claro que existentes desvantagens, uma delas é o número de correções necessárias em caso de erro encontrado nos componentes. O problema pode ser ainda maior caso exista uma falta de documentação ou documentação incompleta do framework e seus componentes.

Desta forma podemos observar que o método da TOTVS Joinville com o uso da ESBC e seu framework trás grandes benefícios par a empresa a curto, médio e longo prazo. Afinal de contas o custo x benefício num desenvolvimento de software é melhorado exponencialmente junto com as novas implementações e complementos elaborados para o framework utilizado.

Sistema Construtor

1. Objetivo
O sistema atende aos funcionários da empresa quanto as suas dúvidas operacionais. Criará uma base de conhecimento acessível via WEB onde estarão cadastradas as melhores práticas de cada área e as soluções implementadas para cada ocorrência não prevista em tempo de projeto.

2. Descrição
Informações inseridas na base devem ser validadas por um supervisor, engenheiro ou arquiteto.
As informações cadastradas serão classificadas por área, competência e porte da obra.
Autenticação será efetivada pela matrícula, (identificação funcional), com senha.
As consultas estarão disponíveis para todos os usuários do sistema.
A validação positiva de uma nova informação será distribuída via sistema, onde todos os usuários serão notificados, quanto a sua existência.

3. Treinamento
Todos os usuários receberam treinamento ministrado pela empresa desenvolvedora do sistema.

4. Procedimento de Cadastro
Somente será permitido o cadastro pelos usuários mestre de obras, engenheiros ou arquitetos, este sendo validado pelo sistema através de matrícula e senha, abre uma ocorrência informando a área, competência e porte da construção, descrição e possível solução ou procedimento. Após a ocorrência é enviada para aprovação do superior imediato (ver procedimento de validação).
botar img aqui

5. Procedimento de Consulta
Partindo do operário: deve procurar o superior imediato, mestre de obra, passando a ele o problema constatado ou dúvida. O mestre de obra acessando um terminal de consulta do sistema verifica o cadastro do problema ou dúvida, caso não conste ele procura obter a solução e posteriormente registrando no sistema (verificar procedimento de cadastro), sendo o problema ou dúvida encontrado é exibido para visualização. Partindo do mestre de obra, engenheiro ou arquiteto, este, acessando um terminal de consulta do sistema verifica o cadastro do problema ou dúvida, caso não conste ele procura obter a solução e posteriormente registrando no sistema (verificar procedimento de cadastro), sendo o problema ou dúvida encontrado é exibido para visualização.

6. Procedimento de Validação
Todas as novas informações deverão ser verificadas, corrigidas e validadas pelo engenheiro ou arquiteto, quando uma nova informação for inserida no sistema esta será encaminhada para o responsável mediante cruzamento de dados (área e competência), e ficará pendente de validação. Sendo aprovado ou reprovado o solicitante será informado mediante visualização no sistema.

7. Autenticação
O usuário passar o crachá em um leitor óptico ou informa diretamente o código da matrícula e após a senha para autenticação no sistema.

Construtora

O Problema

Ao iniciar o desenvolvimento de um novo projeto e/ou execução de uma obra solicitada pela construtora, não repetir erros cometidos no passado aumentando as chances de sucesso ao mesmo. Erros recorrentes com soluções muitas vezes diferentes estão causando uma perda de rendimentos a empresa.

Solução
Como proposta de solução, foram levantadas três frentes distintas para cobrir todas as áreas de abrangência do sistema, sendo elas: workflow, catalogação e pesquisa de histórico.

Workflow

Entrada de dados:

Arquitetura:

a) Desenho Segundo especificações do cliente;

b) Tipo de arquitetura

Engenheiro:

a) Análise do desenho: aprova ou não

b) Ambiente natural do local;

c) Tipo de obra;

d) Quantidade de andares;

e) Tamanho da obra;

f) Quantidade de algum material utilizado na obra;

g) Custo da obra; 

h) Se não foi aprovado, vai pra Arquitetura para redesenho,

Se for aprovado, segue para o mestre de obras Mestre de obras:

a) Uso de ferramentas;

b) Problemas resolvidos;

c) Os profissionais que trabalharam na obra;

d) Fornecedores;

e) Marcas dos materiais utilizados;

f) Nível de segurança do local; 

g) Analise durante o desenvolvimento da construção :

Se houver problemas, cadastra os dados: 

Área específica, definida por ele, e a descrição do problema

Se não houver, continua.

Enquanto nào terminar a construição, fica na analise do mestre.

Catalogação.
Durante este processo, serão realizados os cadastros que dizem respeito ao momento da obra, tornando assim cada situação um novo dado histórico que permita ser consultado posteriormente. A catalogação se dará de forma categorizada, principalmente dividindo em três grandes grupos: peculiaridades encontradas, problemas insolúveis e problemas solúveis. Para cada uma destas três situações o atualizador terá o poder de tecer comentários a respeito de seu problema, e quais medidas foram tomadas na ocasião.

A catalogação não abordará apenas problemas técnicos, mas sim situações corriqueiras e principalmente identificará responsáveis pelas atividades e equipes envolvidas.
O cadastro de tais informações se dará a partir de um computador com acesso a internet, já que o sistema será web

Pesquisa
A parte de pesquisa constitui outra frente importante do sistema, já que será a partir dela que o executante terá base para tomada de decisões. Todos os dados que forem fornecidos durante a etapa de catalogação estarão acessíveis de acordo com o nível de acesso para consulta relatando quais as soluções tomadas.

Como é difícil encontrar um mesmo ambiente em duas situações a pesquisa exige que haja um sistema busca por palavras chaves, para que consiga filtrar as informações fornecidas e busque tais palavras nos projetos cadastrados anteriormente. Assim, baseado em quantidade de vezes que a palavra apareceu, poderá ser feita uma análise de relevância do resultado.
Dados como valores cobrados por fornecedores, quantidades de problemas ocasionados por profissionais (terceiros) específicos, marcas utilizadas, custos de obras e opiniões dadas por clientes também poderão ser consultadas para que se haja uma visão gerencial maior dos projetos.

A pesquisa será um sistema acoplado ao sistema de catalogação. Sendo assim, esta também se dará através de uma interface web.

Usuários do sistema
Inicialmente o foco de atendimento do produto serão os mestres de obras responsáveis pela construção, já que eles serão os concentradores da informação, advindas tanto por parte dos engenheiros quanto por parte dos técnicos (peão). Sua vivencia diária na obra lhe permitirá perceber quais os principais entraves vividos pelos funcionários e quais as soluções adequadas para as tais (geralmente tomadas pelo próprio mestre), permitindo assim alimentar o sistema com sua experiência e/ou ter uma boa base de conhecimento para realizar as pesquisas de histórico aos outros projetos.

Como os problemas não se concentram apenas na fase da execução, os engenheiros também podem/devem consultar o sistema para obter uma maior assertividade no desenvolvimento do projeto, para que tenha maior conhecimento até para que seja repassado aos mestres de obra posteriormente.

A parte executiva da empresa teria acesso ao sistema para tomada de decisões de acordo com o histórico, partindo de conhecimentos de falhas com equipes especificas ou determinados locais.
Por fim, o cliente poderá contribuir com idéias a respeito do que lhe foi entregue, apontando falhas perceptíveis a leigos, imperfeições visuais ou qualquer outro problema que ele tenha percebido após o término da obra.

O que deverá ser catalogado e poderá ser pesquisado?

Alguns dados importantes para serem cadastrados, para que assim fique mais fácil realizar a pesquisa bem como fazer o relacionamento de informações pela inteligência artificial:
-Ferramentas utilizadas durante as operações
-Profissionais envolvidos e suas respectivas tarefas
-Fornecedores
-Marcas utilizadas
-ambiente natural do local
-Segurança encontrada no local da obra
- tamanha da obra (metragem);
- custo da obra
- tipo de arquitetura

Interfaces
Para prover o cadastro de todas estas informações foram previstas as seguintes telas para o sistema:
-cadastro de atividades
-cadastro de funcionários
-cadastro de fornecedores
-cadastro de materiais
-Cadastro de plantas
-Cadastro de obra
-busca de atividades por palavra chave
-busca de atividades por profissionais
-busca de custo por projetos
-busca de profissionais por projetos
-busca quantidade de problemas por profissionais

Diagramas:

Caso de uso Geral

Diagrama de Sequência de Cadastro para pesquisa

Diagrama de Sequência de pesquisa

fluxograma do workflow

Sist. Ger. Construção

SISTEMA DE GERENCIAMENTO DE PROJETOS DE CONSTRUÇÃO CIVIL – SisCom

Introdução
Objetivo do sistema (SisCom) é gerenciar as informações de forma automatizada e acessível para minimizar perdas e retrabalho e maximizar a produtividade num projeto de construção civil.
O SisCom permitirá a interatividade das experiências dos profissionais de execução com os engenheiros de projetos, onde os engenheiros, na fase de desenvolvimento, poderão consultar os problemas e sugestões ocorridos nas obras. Esta interatividade acontece devido ao SisCom permitir que seja classificada a categoria da obra, o estágio, o tipo de serviço e o nível critico dos problemas encontrados.

Funções do Sistema
· Cadastrar, editar, excluir problemas;
· Cadastrar, editar, excluir sugestões;
· Pesquisar problemas através de filtros considerando:
o O tipo de imóvel;
o A etapa da obra;
o O estágio da obra;
o O nível da obra;
o Gravidade do problema da obra.
· Pesquisar sugestões;
· Gerar relatórios com as melhores sugestões;
· Gerar relatórios com os problemas ocorridos;

Características dos usuários
· Ter noções básicas de informática;
· O usuário deve ter um treinamento na ferramenta;
· Conhecer o processo de sua área.

Níveis de acesso dos Usuários
· Cadastramento de sugestões: Os usuários do SisCom podem inserir novos registros;
· Cadastramento de problemas: Será de acordo com função do funcionário;
· Pesquisas: Os usuários do SisCom podem pesquisar.

Exemplo da tela de cadastro de problema.

Projeto Engenharia SBBC

SISTEMA BASE DE CONHECIMENTO DA CONSTRUÇÃO

INTRODUÇÃO

Propósito

Este documento tem como objetivo definir os requisitos do projeto de base de conhecimento da construção, utilizando o cadastro e aprovação dos conhecimentos adquiridos na construção civil. Desta forma uma base de conhecimento é criada facilitando a evolução das obras.

Escopo

O sistema permite o cadastramento de informações pertinentes às construções que estão sendo realizadas, registrando conhecimento dos funcionários, desvios que aconteceram e melhorias que podem ser implementadas. Estas informações que serão registradas antes de terem sua publicação finalizada serão aprovadas por um profissional que tenha o conhecimento necessário para homologar os conhecimentos cadastrados.

Definições, Acrônimos e Abreviações

Mestre de obras: Profissional responsável pela obra e pelos pedreiros, como um coordenador.
Engenheiro: Responsável pela criação do projeto, desempenho, planta, etc.
Arquiteto: Responsável pela criação artística da obra.
SBCC: Sistema Base de Conhecimento da Construção

Organização da Especificação de Requisitos de Software

Este documento está dividido em quatro seções. Na Seção 1, uma breve introdução sobre o conteúdo deste documento foi apresentada. Na Seção 2, uma descrição geral do sistema é apresentada. Na Seção 3, os requisitos específicos do SBCC são descritos. Na seção 4 e final temos uma breve descrição do pós implantação.

Descrição Geral do Sistema

O sistema SBCC tem como principal objetivo o cadastro dos conhecimentos e habilidades adquiridas conforme a experiência de cada funcionário da construção civil. Com este sistema será possível a criação de uma base de conhecimento para as futuras construções garantindo assim a qualidade e a preservação da informação. Serão necessárias reuniões diárias de no máximo 15min entre os funcionários e coordenações para alinhar idéias novas a serem cadastradas e discussão de melhorias (Daily Scrum).

Funções do Produto

O SBCC tem como objetivo realizar o cadastro de informações das obras em andamento para uma base de conhecimento ser criada através das funções:
- Cadastro de novos conhecimentos/habilidades;
- Consulta das informações já cadastradas;
- Aprovação dos cadastros a partir de um profissional capacitado;
- Administração do sistema para a criação dos usuários, permissionamentos, ajustes iniciais do sistema, cadastro das áreas de conhecimento.

Características do Usuário

O SBCC é um sistema destinado aos profissionais da construção civil onde todos os envolvidos na construção poderão cadastrar informações, porém apenas usuários chaves e capacitados poderão fazer a aprovação para a publicação destas informações.

Suposições e Dependências

A configuração mínima requerida para a execução do SBCC são microcomputadores pessoais, memória RAM mínima de 128 Mbytes e ambiente Windows 98 ou superior. Além disso, deve conte um navegador (browser) instalado.

Requisitos Funcionais

- O sistema deverá realizar o cadastro de novos conhecimentos, será cadastrado na parte de Incidentes (para desvios que ocorrerão e são conhecidos) e melhorias (melhorias sugeridas para evitar desvios e/ou problemas e manter a qualidade do serviço). Para realização do cadastro será necessária a descrição da ocorrência, pessoa que cadastrou, detalhamento da ocorrência, função da pessoa que cadastrou;
- O sistema deverá possuir um cadastro de usuários, onde serão cadastradas todas as informações do usuário, tais como, matricula, função, nome, idade, experiência, tempo de empresa;
- O sistema deverá realizar pesquisa na base de conhecimento;
- O sistema deverá conter o cadastro de aprovadores por área de conhecimento/responsabilidade;
- O sistema deverá conter a parte de aprovação dos documentos cadastrados, esta pessoa será designada por áreas especificas de conhecimento. A pessoa que definirá quem aprova o que em cada área será o gestor do projeto;

Requisitos de Desempenho

- O sistema deverá apresentar tempo de resposta satisfatório para todas as funções requisitadas pelo pesquisador.

Atributos do Sistema de Software

- O sistema será WEB;
- O sistema possuirá portlets para a consulta rápida;
- O sistema possuirá um Faq e um Wiki para melhor discutir as idéias;
- Sistema deverá ser portátil;
- O sistema deve fornecer uma interface amigável e de fácil utilização.

Diagramas

Diagrama de Casos de Uso:




Diagrama de Atividade:

















Interface







Pós implantação

Serão realizados treinamentos com os multiplicadores para que o sistema seja apresentado e compreendido de forma plena. Estes treinamentos tem por objetivo tirar dúvidas e fazer com que os usuários entendam de forma plena o software, tendo assim um primeiro contato com o sistema.

Projeto Orientado a Objetos

Por ECP360 e BSI360 2008/2

1. Introdução a POO

A programação orientada a objetos veio para solucionar vários problemas que a programação comum não conseguia ou resolvia de forma incompleta. Trata-se de uma linguagem robusta com uma característica de reaproveitamento de código, melhor organização, desta forma facilitando a vida de programadores e analistas graças às facilidades que este tipo de linguagem proporciona.
Temos hoje no mercado diversas ferramentas para programação da POO, mas nem todas são exploradas ao máximo ou da forma correta, muito ainda neste setor existe para ser explorado, descoberto e desenvolvido.

Claro que mesmo sendo tão eficiente e tendo tantos recursos a POO ainda tem pontos de falha e que devem ser tratados. Não apenas as limitações podem trazer problemas para o desenvolvimento, mas ainda existe a limitação de quem desenvolve, sendo que muitas vezes algumas pessoas não estão preparadas e não tem conhecimento suficiente da estrutura orientada a objeto e acaba fazendo o mau uso da mesma e neste caso uma codificação ruim pode ser fatal para o programa.

Este é um assunto muito abrangente e causa muitas discussões, porém sempre é importante debater assuntos deste nível. Sempre é importante estudar um pouco mais sobre um assunto tão abrangente e tentar entender cada vez mais seus conceitos e fundamentos.

Objetos:

Objetos são elementos como na vida real, eles tem propriedades, estados, ações e partes. Um exemplo é um carro que possui quatro rodas que formam as partes do mesmo ou fazem parte de outros objetos, propriedades como potência do motor, estados como ligado/desligado e ações como acelerar.

Na POO, os objetos seguem a mesma linha, com objetos possuindo propriedades, outros objetos internos, como o exemplo do carro e métodos que definem seu comportamento.

Classes:

A classe pode ser definida como uma família onde todos os elementos contidos nesta seguem uma estrutura e funções definidas. Em relação à programação, a classe define os atributos e funções do objeto, então, ela descreve um conjunto de objetos semelhantes.

Todo objeto criado a partir de determinada classe é uma instância dessa classe, pois todas as informações contidas no objeto serão estruturadas de acordo com a classe.

A existência da classe proporciona uma organização e reusabilidade do código, caso não houvesse a classe em cada nova criação do objeto haveria a necessidade de descrever toda a estrutura desse novo objeto, assim, com o uso de classes pode-se padronizar os objetos.

Vantagens:

Reuso de código: É sem dúvida a maior vantagem da POO, pois permite que programas sejam escritos rapidamente garantindo que os mesmos estejam livres de erros, pois já foram testados anteriormente. Esta técnica é possível através de mecanismos de herança e interface.

Escalabilidade: É a capacidade de uma aplicação crescer sem aumentar sua complexidade ou comprometer seu desempenho. Graças à estrutura de objetos e classes, cada entidade do sistema agrupa suas funcionalidades específicas e se comunica com outras partes por mensagens.

Manutenção Fácil: É seguro, portanto mais fácil de manter. O encapsulamento ajuda a proteger as informações de cada classe, de modo que apenas seus objetos tenham acesso às informações que quando disponibilizadas externamente necessitam do consentimento do criador.

Apropriação: Polimorfismo permite tornar o programa mais enxuto, já que um método pode receber uma referência genérica e executar operações genéricas dessa classe. Graças ao mecanismo de interface e herança o sistema, fica em termos de manutenção, mais fácil de ser entendido e modificado.

Desvantagens:

Apropriação: É tanto uma vantagem quanto desvantagem. O mecanismo de interfaces e heranças quando utilizado de maneira errada, pode mais prejudicar do que ajudar sua aplicação. Na vida real é muito fácil dividir o mundo em categorias e grupos, na POO essa associação nem sempre é tão simples.

Fragilidade: Se os relacionamentos entre as classes mudam, muitas vezes é necessário remodelar o código e reprojetar uma nova hierarquia de classes. Se existir alguma falha durante esse processo, pode ser que o mesmo não seja tão facilmente identificado.

Linearidade de Desenvolvimento: O desenvolvimento precisa seguir uma linha e passar por todas as etapas de um projeto possível. Precisa que cada processo faça sua parte bem feito, porque uma é altamente dependente da outra. Além disso, a POO necessita de um projeto cuidadoso de hierarquia de classes, um erro aqui pode comprometer o bom desenvolvimento de toda uma aplicação.

2. UML (Unified Modeling Language)

História
A UML teve inicio após uma tentativa de Jim Rumbaugh e Grady Booch de relacionar dois métodos populares de modelagem orientada a objeto. O primeiro método é o Booch e o segundo é OMT (Object modeling language), esta união ocorreu no ano de 1994. Logo após essa parceria no ano de 1996 o criador do método Objectory juntou-se aos dois formatos (Booch e OMT), formando assim a primeira versão da linguagem UML(Unified Modeling Language).

Objetivos da UML
A UML tem como objetivos a modelagem de sistemas usando conceitos da orientação a objetos. Outro critério é estabelecer uma união com métodos conceituais que sejam executáveis.
A criaçao de uma linguagem de modelagem usável tanto pelo homem quanto pela máquina também é um dos objetivos da UML.

Futuro da UML
Pelo fato da UML ter como base técnicas antigas e marcantes da orientação de objetos, outras linguagens influenciarão as novas versões.
Técnicas avançadas de modelagem também podem ser definidas usando como base UML, estendendo-a, sem necessidade de redefinir a estrutura interna.
A UML tem integrado muitas idéias, e esta integração contribui para o desenvolvimento de softwares orientados a objetos.

Conceito UML
UML é uma linguagem que presa pela gestão visual para modelar um sistema orientado a objeto. Prezando por três perspectivas:
• Diagrama de classses – (dados estruturais);
• Diagramas de caso de uso – (operaões funcionais);
• Diagramas de seqüência, atividades e transição de estados – (eventos temporais);

Ele utiliza dos diagrmas para estar explicando um sistema. Onde tem como partes fundamentais os Atores e os Use Cases. Que por sua vez fazem toda a interação do sistema.
Temos assim os atores como as partes interativas do sistema (pessoas, dispositivos e outros). Já os use cases são as ações que interagem os atores.
Fica assim modelado o uso dos use case e os atores nos diagramas para uma apresentação detalhada do sistema.

O uml possui esses e outros elementos para criar os diagramas, para poder representar uma determinada parte do sistema ou um ponto de vista do sistema. Temos os seguintes diagramas:
- Caso de uso que vem mostrar os atores e seus relacionamentos;
- Classe que mostra o relacionamento entre as classes;
- Seqüência mostra os objetos e uma sequencia das chamadas do método feito para outros objetos;
- Colaboração mostra os objetos e seus relacionamentos, dando enfase aos que trocam mensagens;
- Estado mostra a mudança de estado e eventos num objeto ou parte do sistema;
- Atividade mostra as atividades ou troca de atividades em uma parte do sistema;
- Componente mostra a programação de alto nível;
- Distribuição mostra a instância dos componentes e seus relacionamentos;

Elementos da UML
De estrutura:
Modelação de estrutura ou Structure Modeling são as partes estáticas de um modelo, representando elementos conceituais ou físicos.
É neste modelo que entram os conceitos de:
• Classe
• Interface
• Componente
• Colaboração
• Nó

De comportamento:
É a modelação do comportamento (o estado) e troca de mensagens de vários tipos de sistemas, é usado, geralmente, para criar ferramentas para estudar estes comportamentos em situações extremas, sem ter que aplicar estas condições pelo fato de, por exemplo, ser muito caro este tipo de teste. Dentro deste Modelo podem ser aplicados os diagramas de Sequência, colaboração, transição de dados e atividades.

É neste modelo que entram os:
• Casos de uso
• Interação
• Máquina de estados

De agrupamento:
Modelação de agrupamento é a organização da UML do projeto em grupos.
Neste modelo entram os conceitos de:
• Pacote
• Modelo
• Subsistema
• Framework

De anotação:
Modelação por anotação são todas as partes explicativas do UML, neste modelo são utilizados todos os comentários que foram feitos e documentados no decorrer do projeto para descrever, detalhar e remarcar todos os elementos no modelo.
Neste modelo entra o conceito de:
• Notas

Relacionamentos
• Dependência
• Associação (bidirecional ou unidirecional)
• Generalização
• Agregação
• Composição

Uma dependência indica a ocorrência de um relacionamento entre dois ou mais elementos do modelo, onde uma classe cliente é dependente de alguns serviços da classe fornecedora, mas não tem uma dependência estrutural interna com esse fornecedor.Por exemplo, Uma mudança no elemento independente irá afetar o modelo dependente. Como no caso anterior com generalizações, os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante.

Quando uma classe recebe um objeto de outra classe como parâmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma dependência entre estas duas classes, apesar de não ser explícita.

Associação são relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes.

A associação pode existir entre classes ou entre objetos. Uma associação entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instância de Professor (um professor específico) vai ter uma associação com uma instância de Disciplina. Esta relação significa que as instâncias das classes são conectadas, seja fisicamente ou conceitualmente.

Generalização é a capacidade de se criar superclasses que encapsulam estrutura e/ou comportamento comuns a várias subclasses. Os procedimentos para se obter a generalização são:
• Identificar similaridades de estrutura/comportamento entre várias Classes.
• Criar a superclasse para encapsular a estrutura/comportamento comum.
• As classes originais passam a ser subclasses da nova superclasse criada.

Uma maneira relativamente fácil de se entender isso, é comparando com a nossa herança genética: Você possui algumas características de seus Pais. Mas seus Pais não possuem suas características. Pois bem, você seria uma subclasse.

Agregação é uma forma especializada de associação na qual um todo é relacionado com suas partes. Também conhecida como relação de conteúdo.

É representada como uma linha de associação com um diamante junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações.

Composição é uma agregação onde uma classe que está contida na outra "vive" e constitui a outra. Se o objeto da classe que contém for destruído, as classes da agregação de composição serão destruídas juntamente, já que as mesmas fazem parte da outra.
É representada como uma linha de associação com um diamante preenchido junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações.

3. Comunicação de objetos

RPC
Chamada de procedimento remoto (ou RPC, Remote Procedure Call) é uma tecnologia de comunicação entre processos que permite um programa de computador chamar um procedimento em outro espaço de endereçamento. O programador não se preocupa com detalhes de implementação dessa interação remota. O metodo remoto é invocado da mesma maneira que um metodo local.

RPC é uma tecnologia popular para a implementação do modelo cliente-servidor de computação distribuída. Uma chamada de procedimento remoto é iniciada pelo cliente enviando uma mensagem para uma servidor remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. Uma diferença importante entre chamadas de procedimento remotas e chamadas de procedimento locais é que, no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, não há nem mesmo garantia de que o procedimento foi invocado.

RMI
O RMI (Remote Method Invocation) é uma interface de programação que permite a execução de chamadas remotas no estilo RPC em aplicações desenvolvidas em Java. É uma forma de implementar um sistema distribuído em plataforma Java. A grande vantagem do RMI em relação ao RPC se dá ao fato de ser possível invocar métodos de objetos remotos e transferir objetos entre estes.

Herança
É o mecanismo pelo qual uma classe herda os atributos/métodos de outras. Assim, uma característica implementada em uma classe pode ser "copiada" para a outra sem reescrever o código.
Utilizando herança, têm-se os seguintes relacionamentos:

• Subclasse: É a classe “filha” que herda de uma ou mais classes suas caracteristicas.
• Superclasse: É a classe “pai”, da qual outras classes irão herdar as características
Herança Simples x Herança Múltipla
• Quando uma classe é subclasse de apenas uma superclasse, essa é uma herança simples.
• Quando uma subclasse herda de duas ou mais superclasses, essa é uma herança múltipla.

Problemas Herança Múltipla
Apesar de ser mais "poderosa" que a herança simples, por permitir que uma classe herde as características de diversas classes, a herança múltipla traz alguns problemas: O que fazer quando as superclasses têm características "conflitantes"?
Isso é chamado de problema diamante.

Interface
É um “contrato” no qual todas as classes que o programam devem seguir. Descreve as características externas (publicas) que uma classe tem. Nelas contem as assinaturas de métodos (nome, parâmetros e valor de retorno). Dessa forma, todas as classes que implementam uma interface, devem implementar os métodos nela contidos.

Polimorfismo
O polimorfismo permite que uma classe seja tratada como uma de suas superclasses ou como uma interface que ela implementamodelo das classes a qual foi concretas a qual foi referenciada. Assim, um mesma classe pode apresentar várias formas. O termo polimorfismo tem o significado de "muitas formas" (poli = muitas, morphos = formas).

Digamos que exista uma classe responsável por caracterizar um objeto GERENTE, porem o objeto Gerente herda caracteristicas do objeto EMPREGADO que o mesmo herda de PESSOA. O Polimorfismo nos oferece a mobilidade de lidar com nosso objeto GERENTE em qualquer formato de objeto do qual foi herdado, tanto com seus atributos como com seus metodos.

Associação
São relações entre classes, representando a possibilidade de relação entre os objetos, permitindo que um objeto utilize os recursos de outro, podendo existir mais de uma associação.
Por exemplo: uma pessoa abre a porta; a maçaneta faz parte da porta.

Coesão
Coesão é uma medida de integridade conceitual de uma classe - o objetivo, nesse caso, é o de maximizar a coesão para assegurar agrupamento de operações e com isso reduzir esforços de manutenção.

Encapsulamento
Um dos pontos da POO é o de esconder dados dentro de Objetos, os quais são manipulados por funções(Métodos). Estas estruturas não devem ser visíveis para outros objetos, apenas pelos métodos dentro do objeto à que ele pertence, aos outros objetos somente aparecem os métodos existentes. Na classe são criados atributos(Estruturas de dados) para o armazenamento de uma maneira privada e são implementados métodos (públicos) que manipulam estas estruturas.

Acoplamento
O acoplamento é uma medida de quanto uma classe esta ligada a outras classes, tendo conhecimento das mesmas ou sendo dependente delas.
Uma classe com baixo (fraco) acoplamento não depende de muitas outras.
Uma classe com alto (forte) acoplamento é:

• Mais difícil de compreender isoladamente;
• Mais difícil de reutilizar (seu uso depende da reutilização das outras classes da qual ela depende);
• Sensível a mudanças nas classes associadas

4. Tipos de objetos

Servidores: O objeto servidor tem a função de servir a um outro objeto que possa se fazer necessário em um determinado momento. Enquanto um objeto servidor não está servindo a um outro objeto sua execução é interrompida até que esse se torne necessário novamente. Um exemplo que podemos usar é: um determinado objeto tem um método de impressão, ele só se fáz necessário no momento em que o usuário deseja imprimir algum documeto. Quando esta necessidade existe este objeto é chamado e utilizado, porém enquanto ninguém necessitar o seu uso ele continua parado.

Objetos concorrentes: Objetos concorrentes são quando dois objetos estão executando processos de forma simultânea, e inclusive podem se comunicar-se um com o outro. Porém eles são independentes e executam as suas atividades de forma separada. Um exemplo seria o uso de threads, onde é possível criar dois processos concorrentes que executem duas tarefas diferentes em um mesmo programa, e ainda uma esperando uma determinada resposta da outra quando necessário.

Objeto Ativo: é o objeto que executa as atividades, ele é o objeto responsável pela linha de execução. É ele que executa as tarefas quando estimulado.Ele sempre está em modo de execução, ao contrário do objeto do tipo servidor pois está sempre sendo executado.

Objeto Passivo: o objeto que é desprovido de capacidade de execução, sua função é basicamente enviar estímulos a objetos ativos para que eles por sua vez executem alguma atividade. Um exemplo seria um sensor que recebe um sinal de temperatura alta indicando um incêndio. Porém o sensor em sí não tem capacidade de apagar o fogo, assim ele estimula o
sistema anti-chamas a fazer a extinção do fogo.

5. Rational Unified Process (RUP)

É um processo proprietario de engenharia de software criado pela Rational Software Corporation posteriormente adquirido pela IBM. Trata-se de uma metodologia utilizada para gerenciar grandes projetos de software, utilizando uma abordagem de orientação de objetos e a notação UML para sua documentação.

Características:
• Uso de iterações para evitar o impacto de mudanças no projeto,
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

Fases do projeto:
• Concepção - entendimento da necessidade e visão do projeto,
• Elaboração - especificação e abordagem dos pontos de maior risco,
• Construção - desenvolvimento principal do sistema,
• Transição - ajustes, implantação e transferência de propriedade do sistema

O RUP se baseia nos 4 P’s
• Pessoas
• Projeto
• Produto
• Processo

As fases do projeto são compostas de uma ou mais iterações, sendo semelhante ao modelo espiral. As iterações são definidas em um determinado período de tempo geralmente curtos.
Conteúdo do RUP

Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos.

Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.

Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário.

Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos (artifacts) gerados ao longo do projeto. Os documentos são totalmente compatíveis com a UML, o que reforça a questão de padronização.

Análise de risco – Consiste em analizar os possiveis riscos durante o projeto, procurando metodos para evita-los ou trata-los.

Gestão de mudança – a gestão de mudança visa lidar com as mudanças de requisitos ao longo do projeto.

6. Identificação de Objetos

Identificação de objetos é o processo de análise para identificação e modulação dos objetos e classe de um sistema. Esta tarefa não é fácil, pois requer que o projetista tenha habilidade e experiência sobre os processo que envolvem a utilização do sistema, além de não ter um método específico, mas apenas um conceito.

Abaixo é descrito um exemplo que servirá de base para o entendimento do assunto.
"Uma empresa solicita o desenvolvimento de um software que faça o gerenciamento do Recursos Humanos da empresa. Para isto, foram determinados certas regras, na qual o empregado possui uma identidade própria, seu nome. Possui também propriedades como: endereço, idade, dependentes, salário, cargo. Neste sistema também são encontrados avaliações que os empregados realizam. O RH organiza eventos da empresa para seus colaboradores, dependentes e a sociedade. No sistema o comportamento pode ser determinado por operações como: aumentar salário, listar dependentes e alterar cargo. As propriedades somente podem ser manipuladas através das operações definidas na interface do objeto, de modo que a forma de armazenamento das propriedades e a implementação das operações são desconhecidas pelas outras entidades externas."

Para identificamos objetos ao um sistema é interessante enxergamos o primeiramente mundo real assim como na história acima o mundo real é o setor de recursos humanos, então deve-se olhar os processos envolvidos no RH.

Pode-se identificar no exemplo acima o objeto Empregado, na qual carrega as seguintes propriedades: endereço, idade, dependentes, salário. Também é identificado o objeto Avaliação que pode carregar as seguintes propriedades: nome, tipo de avaliação, pré-requisitos.

Alguns objetos são considerados abstratos, pois não são objetos palpáveis. Estes objetos são mais difíceis de enxergar, no exemplo citado existe dois objetos abstratos: Evento e Cargo, onde as propriedades para Evento são: nome do evento, tipo de evento, freqüência, quantidade de convidados; e para Cargo: nome do cargo, nível do cargo, salário base do cargo.

7. Modelos de Projeto

Os modelos de projetos mostram as classes de objetos e as relações entre elas. São divididos em modelos estáticos e modelos dinâmicos.

Os modelos estáticos descrevem basicamente a estrutura estática do sistema e como elas se relacionam.

Os modelos dinâmicos por sua vez, descrevem a interação dos objetos em tempo de execução.

Eles não precisam ser necessariamente UML, podem ser modelos RUP ou modelos próprios.

Exemplos de modelos UML:

Modelo de caso de uso (estático):

Modelo de Subsistema (estático): Mostra como o projeto é organizado em grupos de objetos relacionados.

Modelo de sequência (dinâmico): modelam a seqüência das interações entre os objetos.

Modelo de Estado (dinâmico): mostram os estados dos objetos individuais.

Modelo de transição (estático): é uma representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema.

Modelo de atividades (dinâmico)

Diagrama de colaboração (dinâmico)