sexta-feira, 22 de junho de 2012

Resultado das Avaliações Individuais da II unidade - 2a chamada


ATENÇÃO:
Alunos que fizeram segunda chamada da Avaliação Individual da II Unidade das disciplinas:



  • ENGENHARIA DE SOFTWARE II
  • ANALISE E MODELAGEM DE SISTEMAS II
  • ANALISE E MODELAGEM DE SISTEMAS I


Assim que eu receber suas provas, atualizo as notas.

NA DÚVIDA, ESTUDE PARA A VERIFICAÇÃO FINAL!

As finais serão iniciadas na terça feira, de acordo com o calendário da FTC.

Boa sorte a todos.

quinta-feira, 21 de junho de 2012

Parabenizações as apresentações de TID I, II e III.

Fiquei, particularmente, muito contente com a qualidade das apresentações de todos os T.I.D.´s.

Obvio que alguns abordaram (quando) muito superficialmente a questão central do tema: "Como a computação pode ajudar as energias sustentáveis". Entretanto o ocorrido não desabona o resultado das pesquisas. 

Tenho convicção de que muitas das pesquisas apresentadas, com roupagem adequada, pode ser apresentada em congressos e transformados em artigos e trabalhos de conclusão de curso.

PARABÉNS A TODOS !
















quarta-feira, 20 de junho de 2012

Assuntos e Datas da Verificação Final


Disciplina _______________________________________ Data             

4ºSEM. Engenharia de Software II _________________ 27-06-2012

Assuntos: Processos de Software, Reengenharia, Gerencia de configuração, Desenvolvimento Distribuído de Software, Refatoração, Manutenção.

1ºSEM. Introdução a Sistemas de Informação _______ 28-06-2012

Assuntos: Conceito de dados, informação e conhecimento, Classificação dos Sistemas, Recursos e Tecnologias dos sistemas de informação.

5ºSEM. Analise e Modelagem II ____________________ 26-06-2012
6ºSEM. Analise e Modelagem II ____________________ 26-06-2012

Assuntos: Diagramas da UML (todos), Modelagem do Comportamento do Sistema, Introdução, Elaboração e Analise de Gestão de Projetos. 

4ºSEM. Analise e Modelagem I _____________________ 29-06-2012

Assuntos: Visão geral da modelagem aplicada ao processo de desenvolvimento de software, Diagramas da UML (uso, atividade, classe, estado, sequencia, componentes e implantação)


3ºSEM. Engenharia de Software I __________________ 29-06-2012

Assuntos: Processos de Software, Engenharia de Requisitos, Verificação e Validação, Teste de software, Métricas, Manutenção de Software.


BOA SORTE A TODOS!

quinta-feira, 14 de junho de 2012

Resultado das Avaliações da Unidade

Caros alunos, favor conferir sua caderneta eletrônica.

Parabéns à aqueles que foram aprovados sem necessidade de verificação final.

Para aqueles que, eventualmente, precisem da Verificação Final de Aprendizagem, breve será postado os assuntos por disciplina bem como as datas das avaliações.

Até breve e boa sorte a todos.

sexta-feira, 25 de maio de 2012

Avaliações 2012.1 - UNIDADE II

Atenção: as datas das avaliações podem ser mudadas em virtude das avaliações do VMD.
Avaliação VMD: 01/06/2012
Feriados em Junho: 07,13 e dia 24.

Resumo

Disciplina________________________________________AI_______AG
4ºSEM Engenharia de Software II _________________ 30/05/12 06.06.12
1ºSEM Introdução a Sistemas de Informação _______ 31/05/12 14.06.12
5ºSEM Analise e Modelagem II ____________________ 05/06/12 29.05.12
6ºSEM Analise e Modelagem II ____________________ 05/06/12 29.05.12
4ºSEM Analise e Modelagem I _____________________ 08/06/12 18.05.12
3ºSEM Engenharia de Software I __________________ 11/06/12 18.06.12
3ºSEM Trabalho Interdisciplinar Dirigido I ______ 20/06/12 
TEMA: COMO A COMPUTAÇÃO PODE AJUDAR AS ENERGIAS SUSTENTÁVEIS.




Detalhe

Analise e Modelagem de Sistemas I - 4º semestre
  • Avaliação Individual (08/06): classe, estado, sequencia. 
  • Avaliação Grupo (18/05): classe - concluído 
Engenharia de Software II - 4º semestre
  • Avaliação Individual (30/05): gerencia de configuração, DDS 
  • Avaliação Grupo (06/06): refatoração, manutenção (até três pessoas)
Analise e Modelagem de Sistemas II - 6º semestre
Analise e Modelagem de Sistemas II - 5º semestre

  • Avaliação Individual (data): 05/06/2012 
  • Modelagem do comportamento do Sistema 
  • Padrão para atribuir responsabilidades 
  • Gestão de projetos 
  • Diagramas da UML (uso, classe, atividade) 
  • Avaliação Grupo: 
  • 28/05/2012 (entrega dos projetos) - concluído 
  • 29/05/2012 (apresentações) - concluído 
Introdução a SI - 1º semestre
  • Avaliação Individual (31/05): 
  • Sistema de informação manual x computadorizados 
  • Recursos e Tecnologias dos sistemas de informação 
  • Avaliação Grupo (14/06): 
  • ERP. Dividir a sala em três equipes; Pesquise na internet um sistema ERPs e apresente em sala (não pode haver repetição de ERPs ). Com base nas características dos ERP’s, já estudados, visite uma empresa em sua cidade, faça levantamento das necessidades desta empresa e justifique tendo como base a literatura especializada se a empresa precisa de um ERP ou não levando em consideração a competitividade empresarial. 
Engenharia de Software I - 3º
  • Avaliação Grupo (18.06) (equipe com até três alunos):
  • Teste de software, Métricas (objetivo, motivação, definição, papeis, plano, tendência, etc.)
  • Avaliação Individual (11.06):
  • Introdução, Elaboração e Analise de Gestão de Projetos , manutenção
TID I - 3º Avaliação Individual:
  • (Banca de avaliação: Antônio Luís, Rômulo, Morais).
  • Apresentação dos projetos (20/06) : 

domingo, 15 de abril de 2012

MODELAGEM DE SOFTWARE


Pessoal, como a UML tem uma importância impar para o desenvolvimento das disciplinas Analise e Modelagem e Engenharia de Software - disciplinas que ministro, resolvi em tempo, disponibilizar aos interessados, mais um material complementar de estudo: o conteúdo abaixo.

Não se esqueçam de dar ênfase nos estudos sobre histórico da UML, na especificação da UML 2, na classificação quanto a organização da UML 2 e na definição dos Diagramas da UML 2 pois o domínio desses assuntos podem ajuda-los nas avaliações. 

Bons estudos e boa sorte.

MODELAGEM DE SOFTWARE

O crescimento vertiginoso dos softwares nas ultimas décadas teve, crescimento foi acentuado na década de 1990 com o início da massificação da tecnologia onde o número de novos softwares aumentou e ocasionando o surgimento de uma variedade muito grande de formas de modelagem para os sistemas orientados a objeto. Todavia, para se construir um software de qualidade são necessários grandes esforços e muita experiência. A esse respeito Silva e Videira (2001) afirmam:
Fazer software não é uma tarefa fácil. Fazer software de qualidade é ainda mais difícil. A generalidade dos resultados obtidos ao longo do tempo têm sistematicamente apresentado padrões de baixa qualidade, de custos e prazos completamente ultrapassados. (SILVA; VIDEIRA 2001, p.27)

Nesse sentido, com a necessidade de criar processos padronizados para o desenvolvimento de software, que surgiu o UML por volta de 1996 unificando as notações e diagramas. A UML (Unified Modeling Language ou Linguagem Unificada de Modelagem, em português) é uma linguagem visual para a modelagem de sistemas orientados a objeto, permitindo uma melhor visualização padronizada de um sistema.

A esse respeito Silva e Videira (2001) definem:

A ênfase do UML é na definição de uma linguagem de modelação standard, e, por conseguinte, o UML é independente das linguagens de programação, das ferramentas CASE, bem como dos processos de desenvolvimento. (SILVA; VIDEIRA 2001, p. 143)

A evolução da UML desde a sua criação até o ano de 2002 pode ser melhor visualizado a partir da análise da Figura abaixo.

Evolução da UML. 
Fonte: Adaptado de http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/historia_uml/historia_uml.htm


Como principais objetivos da UML destacam-se: simplicidade, especificação, documentação e estruturação. 

Segundo Silva e Videira (2001, p.145) os tipos de diagramas da UML podem ser classificados, destacando-se: os Diagramas de Casos de Uso; Diagramas de Classes e de Objetos; Diagramas de Comportamento. Os Diagramas de Comportamento se subdividem ainda em Diagramas de Estados; Diagramas de Atividades e Diagramas de Colaboração. E, por fim os Diagramas de Arquitetura são classificados como Diagramas de Componentes e Diagramas de Instalação.

A especificação de UML é composta por quatro documentos: infra-estrutura de UML(OMG, 2006), superestrutura de UML (OMG, 2005c), Object Constraint Language (OCL) (OMG, 2005a) e Intercâmbio de Diagramas (OMG, 2005b). 


  • Infra-estrutura de UML: O conjunto de diagramas de UML constitui uma linguagem definida a partir de outra linguagem que define os elementos construtivos fundamentais. Esta linguagem que suporta a definição dos diagramas é apresentada no documento infra-estrutura de UML.
  • Superestrutura de UML: Documento que complementa o documento de infra-estrutura e que define os elementos da linguagem no nível do usuário.
  • Linguagem para Restrições de Objetos (OCL): Documento que apresenta a linguagem usada para descrever expressões em modelos UML, com pré-condições, pós-condições e invariantes.
  • Intercâmbio de diagramas de UML: Apresenta uma extensão do metamodelo voltado a informações gráficas. A extensão permite a geração de uma descrição no estilo XMI orientada a aspectos gráficos que, em conjunto com o XMI original permite produzir representações portáveis de especificações UML.


Quanto a organização dos diagramas da UML 2.0 pode-se classifica-los em Diagramas Estruturais, Diagramas de comportamento e diagramas de interação.  Veja a imagem abaixo:

Figura: Organização dos diagramas de UML 2


Diagramas Estruturais
Diagramas Comportamentais
Diagramas de Interação

Thânia Clair de Souza Vargas (http://www.lavailama.com.br/arquivo/2.pdf) descreve cada um dos 13 diagramas na UML 2 e diz "Um diagrama é uma representação gráfica de um conjunto de elementos (classes, interfaces, colaborações, componentes, nós, etc) e são usados para visualizar o sistema sob diferentes perspectivas. A UML define um número de diagramas que permite dirigir o foco para aspectos diferentes do sistema de maneira independente. Se bem usados, os diagramas facilitam a compreensão do sistema que está sendo desenvolvido". 


Embora a UML tenha oferecido inúmeros e inquestionáveis benefícios procurando padronizar, simplificar, especificar, documentar e estruturar os processos de desenvolvimento de software, independente da linguagem de programação ou plataforma de desenvolvimento, a UML ainda deixa algumas lacunas como o problema relacionado à semântica, onde desenvolvedores distintos podem diagramar um mesmo sistema de formas diferentes. Na essência do princípio do UML, um mesmo sistema deveria ser diagramado de apenas uma forma, seja pelo desenvolvedor A, seja pelo desenvolvedor B. Todavia esse objetivo ainda não é possível para o UML atual. Talvez, pensando nisso os idealizadores do UML deixaram espaço para que no futuro a questão da semântica do UML seja resolvida



ENGENHARIA DE SOFTWARE


Somente na década de 1968 na  NATO Conference on Software Engineering (Conferência sobre Engenharia de Software da OTAN) a Engenharia de Software ganhou destaque e passou a ser um termo oficialmente usado. Historicamente os primeiros passos do que é entendido como Engenharia de Software na atualidade foi na década de 1960.

Nesse sentido, Mazzola (2010, p. 06) afirma que “engenharia de software é um conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto”. Já para Pressman (2006) a engenharia de software ocorre como resultado da engenharia de sistemas. A esse respeito ele diz:

Antes que o software possa ser submetido à engenharia, o “sistema” no qual ele reside deve ser entendido. Para conseguir isso, o objetivo geral do sistema deve ser determinado: o papel do hardware, software, pessoal, base de dados, procedimentos e outros elementos do sistema devem ser identificados; e requisitos operacionais devem ser conseguidos, analisados, especificados, modelados, validados e gerenciados. Essas atividades são à base da engenharia de sistemas. (PRESSMAN, 2006, p. 99).

Todavia, para a elaboração e implementação de um software ou programa de computador é necessário uma seqüência de práticas. Essa seqüência é conhecida como Processo de Software, ou Processo de Engenharia de Software e englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos.
Dentre várias possibilidades para o desenvolvimento de software, o desenvolvimento tradicional e o desenvolvimento ágil merecem atenção especial. Teles (2006, p.30) define “desenvolvimento tradicional” ou “clássico” quando os projetos de software são “baseados no modelo cascata” ou quando estão muitos próximos desse modelo como o RUP (Rational Unified Process). Esse modelo clássico foi o primeiro processo de desenvolvimento de software publicado (PRESSMAN, 2006).
Segundo Teles (2006) o modelo tradicional, sugere que a construção do programa de computador ou software deve seguir uma linha seqüencial ou fases: Análise onde o desenvolvedor procura buscar e entender as necessidades; Design é a projeção da arquitetura tendo como base a análise; Implementação que é quando a equipe define a arquitetura e as diversas partes do programa de computador; Teste que ajuda a identificar e verificar se o sistema atende aos requisitos específicos definidos pelo usuário; Implantação que é quando o sistema é colocado em operação; Manutenção que ocorre até o final da vida ou seja, até quando o software estiver em operação poderá sofrer alterações.

Para Sommerville (2003), como ilustrado na Figura 08 o ciclo de vida clássico do software tem cinco fases: definição de requisitos, projeto do software, implementação e teste unitário, integração e teste do sistema, operação e manutenção.


Fases do modelo de Desenvolvimento Clássico
Fonte: Adaptado de Sommerville (2003)


O Modelo em Cascata, também chamado de Ciclo de Vida Clássico, é um processo recomendado quando os requisitos de um problema são razoavelmente bem compreendidos, ou seja, quando o trabalho flui da comunicação até a implantação de um modo linear.O Modelo em Cascata, conforme ilustrado na figura 1, sugere uma abordagem sistemática e seqüencial para o desenvolvimento de softwares.
Fonte: http://julianakolb.com/2012/02/01/o-modelo-em-cascata/


Modelo em Cascata.
Fonte: PRESSMAN (2010).



Para o modelo de Desenvolvimento Ágil, Teles (2006, p. 31) refere-se ao desenvolvimento interativo ou espiral, de forma que todas as fases descritas no modelo cascata “sejam executadas diversas vezes ao longo do projeto, produzindo círculos”.