UNIVERSIDADE FEDERAL DE SO CARLOS

DEPARTAMENTO DE COMPUTAO Rodovia Washington Luiz, Km. 235 Caixa Postal 676 Fone: (16) 33518230 Fax: (16) 33518233 CEP 13565-905 So Carlos SP Brasil

Conceitos Preliminares sobre Ciclo de Vida de Software e Modelagem de Sistemas

Prof. Dr. Valter Vieira de Camargo

UNIDADE 1

1 Introduo
Em meados da dcada de 60 um sistema de software era desenvolvido de forma ad-hoc, isto , sem mtodos ou tcnicas adequadas ao seu desenvolvimento, resultando em sistemas mal projetados e que resultavam em enormes problemas de manuteno. Tais sistemas consumiam a maior parte dos recursos (pessoas x tempo x dinheiro) das empresas que os desenvolviam em consequncia do tempo e do nmero de pessoas que eram empregados para mant-los. Quase todo o tempo disponvel era despendido consertando o sistema por causa do grande nmero de erros/falhas e problemas em geral que ele apresentava. Alm disso, boa parte do software no possua documentao e a nica fonte de informao sobre o sistema era seu prprio cdigo fonte no havia documentos ou outros artefatos que descrevessem como o software foi implementado de forma a facilitar, por exemplo, a busca por um erro existente. Na dcada de 70 comeou-se a perceber que o desenvolvimento de sistemas deveria empregar tcnicas mais adequadas para seu desenvolvimento assim como era feito na engenharia, de forma que sua qualidade fosse melhorada e que menos problemas de manuteno fossem encontrados depois que o sistema fosse colocado em operao. Comearam ento a surgir propostas de abordagens de modelagem para projetar sistemas antes que os mesmos fossem implementados. Diversas propostas de modelagem foram criadas, cada qual com uma caracterstica distinta.

2 UML Unified Modeling Language

Os primeiros sistemas eram implementados em linguagens estruturadas como COBOL e C++, seguindo os princpios da programao estruturada. Esse tipo de programao possui como caracterstica principal que os dados e as sub-rotinas (comportamento) so implementados de forma totalmente separada no cdigo fonte. J, com o advento da programao orientada a objetos, os dados e as sub-rotinas passaram

UNIVERSIDADE FEDERAL DE SO CARLOS

DEPARTAMENTO DE COMPUTAO Rodovia Washington Luiz, Km. 235 Caixa Postal 676 Fone: (16) 33518230 Fax: (16) 33518233 CEP 13565-905 So Carlos SP Brasil

a ser codificados juntos, em um mesmo mdulo de programa chamado classe. Aps seu surgimento, vrias tcnicas de anlise e projeto orientados a objetos foram propostas na literatura. Aps o surgimento da programao orientada a objetos, comeou tambm a aparecer vrias propostas para a modelagem de sistemas orientados a objetos, entre elas destacavam-se as abordagens Booch de Grady Booch, a abordagem de Jim Raumbaugh chamada OMT e a abordagem Objectory de Ivar Jacobson. No sentido de definir uma abordagem padro para a especificao de sistemas orientados a objetos, esses trs autores decidiram se reunir e criar a Linguagem de Modelagem Unificada (Unified Modeling Language) ou UML, que se consagrou como a principal linguagem de especificao, visualizao, construo e documentao de sistemas orientados a objetos. Atualmente a UML propriedade da OMG (OMG, 2009), que a definiu como padro em 1997. Maiores informaes sobre a UML podem ser obtidas em Larman, 2007.

3 Noes Preliminares sobre Ciclo de Vida de Sistemas

Qualquer sistema de software possui um ciclo de desenvolvimento e operao que chamado de ciclo de vida. Esse nome foi atribudo porque faz meno ao fato do sistema nascer (seu desenvolvimento), entrar em operao e, eventualmente morrer (sair de operao). O enfoque deste material no processo de criao do sistema, em que tcnicas de modelagem devem ser usadas como apoio ao seu desenvolvimento. O ciclo de vida de um sistema representado esquematicamente pela Figura 1. Note-se que a fase de construo envolve as etapas de levantamento de requisitos, anlise, projeto e construo. A forma de conduzir essas etapas tem forte impacto na qualidade do sistema que produzido. De forma resumida, na etapa de levantamento de requisitos o objetivo levantar o que o sistema deve fazer, isto , o que se espera do sistema em termos de suas funcionalidades. Na etapa de anlise, o responsvel pelo desenvolvimento deve analisar os requisitos e comear a criar uma representao diagramtica do sistema com o objetivo de aprofundar o entendimento dos requisitos e dar suporte fase de projeto. Na etapa de projeto o sistema especificado em detalhes que podem levar em conta a linguagem de programao que ser usada e na etapa de

UNIVERSIDADE FEDERAL DE SO CARLOS

DEPARTAMENTO DE COMPUTAO Rodovia Washington Luiz, Km. 235 Caixa Postal 676 Fone: (16) 33518230 Fax: (16) 33518233 CEP 13565-905 So Carlos SP Brasil

implementao o sistema efetivamente implementado em uma linguagem de programao.

Levantamento de requisitos

Anlise

Projeto

Implementao

construo
tempo Figura 1 Ciclo de Vida de Sistemas.

Operao/ manuteno

Na prtica essas etapas no possuem essa natureza aparentemente seqencial. por isso que na figura existem figuras de ciclos nas etapas e tambm em torno da prpria fase de construo. Isso indica que cada uma das etapas um processo de refinamento em que se obtm um conjunto inicial da soluo e aos poucos incrementase ou refina-se esse conjunto inicial. Alm disso, terminar uma etapa no significa que o responsvel pelo desenvolvimento no ir mais retornar a ela. As setas com linhas tracejadas ao redor de toda a fase de construo mostram que a partir de qualquer etapa pode-se retornar as etapas anteriores para realizar mais refinamentos ou mesmo ajustes que possuem impacto em fases posteriores. Essa estratgia de ciclos a mais real possvel. Invariavelmente, todo desenvolvedor retorna inmeras vezes em fases anteriores para fazer ajustes antes de continuar o processo. Essa caracterstica faz com que o processo mostrado na Figura 1, seja considerado iterativo e incremental. Iterativo significa que vrias iteraes so feitas, isto , uma primeira iterao desenvolve uma verso inicial do sistema passando por todas as etapas mostradas na Figura 1. Uma segunda verso do sistema tambm desenvolvida sobre a primeira novamente passando por todas as etapas e assim sucessivamente. A natureza incremental se d pelo fato de que o sistema vai sendo desenvolvido incrementalmente, em que cada nova verso so adicionadas funcionalidades sobre a verso desenvolvida na iterao anterior.

UNIVERSIDADE FEDERAL DE SO CARLOS

DEPARTAMENTO DE COMPUTAO Rodovia Washington Luiz, Km. 235 Caixa Postal 676 Fone: (16) 33518230 Fax: (16) 33518233 CEP 13565-905 So Carlos SP Brasil

Algo importante a ser observado que todo sistema passa por esse processo, seja ele implcito e existente apenas na cabea dos desenvolvedores, ou explcito na forma de processos burocrticos e bem documentados. A fase de construo na verdade um processo de abstrao top-down, em que se inicia com um entendimento amplo e vago do que o sistema deve fazer e aos poucos caminha em direo aos detalhes de implementao. Isto , parte-se de um alto nvel de abstrao para um baixo nvel. Modelar consiste em empregar determinados diagramas para representar certas caractersticas de um sistema. Como um sistema algo complexo existem vrios diagramas que devem ser utilizados, cada qual com recursos especficos para evidenciar uma determinada caracterstica do sistema. Assim, deve haver um tipo de diagrama que evidencia as caractersticas dinmicas do sistema, outro diagrama que evidencia as caractersticas estticas, outro que evidencia as caractersticas de interao, outro que exibe a sua arquitetura e assim por diante. Existem diagramas que so especficos de etapas do desenvolvimento, por exemplo, os diagramas de casos de uso so especficos para a etapa de levantamento de requisitos. Mas tambm existem diagramas que podem ser usados em mais de uma etapa de desenvolvimento, dependendo do nvel de abstrao desejado. Por exemplo, diagramas de classes podem ser usados tanto em nvel de anlise quanto de projeto. O que ir diferenciar os dois diagramas o nvel de abstrao das duas etapas o diagrama de classes de anlise contm menos detalhes do que esse mesmo diagrama no projeto. Outro ponto importante a ser observado que as tcnicas existentes de modelagem so na verdade tcnicas para se projetar o sistema antes de implement-lo. como o projeto de uma casa feita uma planta da estrutura fsica, uma planta da parte eltrica e outra da parte hidrulica, cada uma evidenciando uma determinada caracterstica ou viso da casa que deve ser construda. Tambm pode existir outra representao que mostre a fachada da casa, e tudo isso feito antes que a construo da casa se inicie. Esses projetos iniciais so usados para comunicao com os proprietrios e fechamento de um contrato de construo. Essa planta pode ser alterada durante a efetiva construo da casa, pois nesse momento, os proprietrios podem perceber que alguma deciso foi tomada errada. Essas alteraes devem ento ser refletidas na planta

UNIVERSIDADE FEDERAL DE SO CARLOS

DEPARTAMENTO DE COMPUTAO Rodovia Washington Luiz, Km. 235 Caixa Postal 676 Fone: (16) 33518230 Fax: (16) 33518233 CEP 13565-905 So Carlos SP Brasil

e o processo de construo continua. O objetivo desse projeto (ou modelagem) justamente permitir que decises sejam tomadas sobre um desenho, pois isso muito mais barato do que construir a casa, averiguar que existem problemas srios e precisar derrub-la para fazer de novo. Alm de servir como guia para a construo da casa, as plantas que so construdas depois ficam como documentao do imvel. Para qualquer alterao estrutural que deva ser feita tempos depois, os engenheiros analisam novamente a planta para averiguar o impacto que alguma modificao pode ter. O mesmo se aplica para um sistema de software os diagramas so inicialmente usados como guias para um bom projeto e como meio de comunicao com os clientes. Durante a implementao, modificaes das mais diversas podem ser necessrias. Depois que o sistema colocado em operao, qualquer manuteno ou necessidade de evoluo deve ento ser apoiada pela documentao existente do sistema.

Referncias Bibliogrficas
OMG. Object Management Group. OMG Unified Modeling Language Specification. Disponvel em: <www.omg.org>. Acesso em: 2 jun. 2009. LARMAN, G. Utilizando UML e Padres, 3a edio, editora Bookman, 2007.