UML

março 3, 2010

É fato que modelagem é essencial para desenvolvermos sistemas de fácil manutenção e de boa qualidade. Porém, vez ou outra escuto alguém com a ideia de que para modelar devemos representar em UML todos os aspectos do sistema antes de iniciar a implementação, chamando isso de etapa de análise e projeto.

Não é novidade que isso não é nada produtivo e totalmente desnecessário. No livro UML Destilled do Martin Fowler, é proposta a abordagem de uso dos diagramas UML como rascunhos, com o objetivo de facilitar a comunicação na modelagem do sistema. Outros profissionais e autores respeitáveis também compartilham desta opinião. Por exemplo, o Ron Jeffries disse recentemente numa lista de discussão:

If you mean by UML occasionally drawing a picture on a bar napkin, I’m all for it. If you mean something more like using full-on UML to draw a comprehensive diagram of the entire object graph, it is a waste of time.

Designing in code works much better than UML for many people, mostly because when you design in UML you get UML and when you design in code you get the program.

Outro que também tem uma opinião parecida é o Robert Martin:

Look, modeling is an abstraction. We purposely suppress details to see the big picture. In order for these ‘modeling’ tools to generate executable code, they need all the details. Well, I have news for you. If you include all the detail, then you’re not modeling! You’re programming, albeit with a different language!

Concordo com eles, a UML é uma excelente ferramenta de modelagem e não uma linguagem de programação. Papel e caneta, ou quadro e pincel são ferramentas UML tão boas quanto o JBuilder ou o StarUML e demais ferramentas CASE.

Anúncios

Modificando as telas do CAS

outubro 5, 2009

O CAS utiliza o conceito de temas para definição do layout de suas telas. Por padrão é aplicado um tema chamado default.
Para modificar o CAS com os seus temas, é necessário o seguinte:

Modificar o arquivo cas.properties, alterando as propriedades cas.themeResolver.defaultThemeName com o nome do seu tema e cas.viewResolver.basename com o nome do arquivo properties que conterá os mapeamentos das views. Por exemplo:


#cas.themeResolver.defaultThemeName=default
#cas.viewResolver.basename=default_views

cas.themeResolver.defaultThemeName=obaoba
cas.viewResolver.basename=obaoba_views

Neste caso, o cas utilizará os mapeamentos de view do arquivo obaoba_views.properties. Portanto, é necessário criar tal arquivo. Basta criar uma cópia do default_views.properties que vem com o CAS e alterar a localização dos jps para um diretório que contenha as sua páginas personalizadas. Neste caso também vale a dica de copiar o diretório existente WEB-INF/view/jsp/default, renomeá-lo e efetuar as suas personalizações. Note que as páginas existentes nesse diretório devem ser referenciadas no arquivo obaoba_views.properties.

Seguindo essas dicas, você estará modificando o tema padrão da sua instalação do CAS. Ainda é possível associar temas aos serviços que são protegidos pelo CAS através do cadastro de serviços, dessa maneira cada aplicação protegida pode ter o seu layout específico na tela de login, tudo isso dentro de uma única instalação do CAS.


Personalizando o CAS

setembro 23, 2009

O CAS (Central Authentication Service) é um projeto open-source com o objetivo de prover a funcionalidade de autenticação única (single sign-on) para aplicações web.

Neste post, explicarei como criar uma versão customizada do CAS para que suas aplicações façam uso do single sing-on da sua maneira.

Seguindo a recomendação do wiki do CAS, uma das maneiras de customizá-lo é criar um projeto maven de uma aplicação web, e adicionar como dependência a aplicação que vem no pacote do CAS.

Digamos que a empresa “Oba oba” queira autenticar suas aplicações utilizando o CAS:

1. Criar diretório para o projeto

mkdir cas-obaoba
cd cas-obaoba
mkdir -p src/main/webapp
gedit pom.xml

2. Criar o pom.xml descrevendo o projeto maven

<?xml version="1.0"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>br.com.obaoba.cas</groupId>
    <artifactId>cas-obaoba</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>war</packaging>
    <name>cas-obaoba - Aplicação de autenticação</name>
    <description>Aplicação JA-SIG CAS customizada para a Oba oba.</description>

    <dependencies>

        <!-- aplicação web do CAS que será personalizada-->
        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-webapp</artifactId>
            <version>3.3.3</version>
            <type>war</type>
        </dependency>

        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-core</artifactId>
            <version>3.3.3</version>
        </dependency>

      </dependencies>
    <build>
        <finalName>cas-obaoba</finalName>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>RELEASE</version>
                <configuration>
                    <source>1.5</source>
                    <target>1.5</target>
                </configuration>
            </plugin>
			<plugin>
				<groupId>org.mortbay.jetty</groupId>
				<artifactId>maven-jetty-plugin</artifactId>
				<configuration>
					<contextPath>cas-obaoba</contextPath>
					<scanIntervalSeconds>5</scanIntervalSeconds>
					<connectors>
						<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
							<port>8080</port>
							<maxIdleTime>60000</maxIdleTime>
							<confidentialPort>8443</confidentialPort>
						</connector>
					</connectors>
				</configuration>
			</plugin>
        </plugins>
    </build>
    <repositories>
        <repository>
            <id>jasig-repository</id>
            <name>JA-SIG Maven2 Repository</name>
            <url>http://developer.ja-sig.org/maven2</url>
        </repository>
    </repositories>
</project>

3. Empacotar o projeto

mvn package

4. Copiar o conteúdo da aplicação web (xmls, jsps, css, javascripts, etc) que será personalizado.

cp -r target/cas-obaoba/* src/main/webapp/

5. Iniciar o servidor de desenvolvimento para confirmar que tudo deu certo.

mvn jetty:run

6. Abra http://localhost:8080/cas-obaoba no browser e verifique se a aplicação foi iniciada corretamente.

Imagem do browser exibindo a aplicação de login do CAS

Imagem do browser exibindo a aplicação de login do CAS

Estes foram os passos básicos para iniciar um projeto de personalização do CAS. A partir deste projeto, é possível alterar o conteúdo que está em src/main/webapp para incorporar o layout da sua empresa, além de modificar as configurações do CAS no arquivo src/main/webapp/WEB-INF/deployerConfigContext.xml para utilizar AuthenticationHandlers específicos da sua instalação, bem como um TicketRegistry real de alta disponibilidade. Assuntos que possivelmente serão tratados em outros posts.


Caixas

maio 13, 2008

Um trecho do livro Você está louco! do Ricardo Semler, um cara que questiona tudo. Neste trecho ele questiona o sistema de ensino e a noção de sucesso em uma teoria curiosa mas bem real, a qual ele chama teoria das caixinhas:

No mundo adulto, a idéia é deixar a vida pessoal para trás, sair de uma caixinha (apartamento) pela manhã, entrar em outra, sobre rodas (ônibus, metrô ou carro) e chegar em outra maior (escritórios ou fábricas sem vista para fora), para ficar o dia inteiro, e voltar via caixa-sobre-rodas para a caixa-mãe. Lá, é sentar na frente da caixinha-com-tela ou daquela caixa-com-Internet, depois cair desacordado por sobre uma caixa-com-colchão. No dia seguinte, transitar novamente entre caixinhas. Que vida!

Na infância, a mãe deixa a criança na porta da escola, muitas vezes contra a vontade da bichinha, para ser “cuidada” e educada por terceiros. Uma caixinha da qual ela não pode sair, na qual ela é empilhada com outras 20 crianças, sem poder sair para o pátio (outra caixinha, aliás, da qual ela também não pode sair).

Se isso for treinamento para uma vida insossa em caixinhas claustrofóbicas, é realmente um sistema exemplar. Se for para ensinar à criança que a vida é cruel, que nunca é possível fazer o que se quer, que mais tarde tudo será assim – cinzento, duro e repetitivo -, então o sistema educacional é um sucesso. Prepara, de fato, a criança para o miserável mercado de trabalho que os pais míopes acham que será igual daqui a 15 anos, quando suas crianças virarem jovens adultos prontos para brigar, competir, atropelar e acotovelar, para serem capazes de comprar caixinhas maiores para morar, caixinhas mais rápidas para dirigir e caixinhas de canto no escritório para trabalhar. Onde pessoas dentro de caixinhas de organograma mandam em caixinhas de cronogramas. Ora…

O que está no âmago do que os pais procuram na educação? Afinal, as crianças são papéis em branco, prontas como esponjas para serem inculcadas com conhecimento e práticas sociais? São matéria-prima para o difuso rei-pagão, o mercado de trabalho? Devem ser sacrificadas no altar do emprego, para então serem declaradas sucesso ou fracasso, dependendo de quanto subirem na hierarquia das caixinhas?

As empresas da era industrial se utilizam bastante das pequenas caixas. Com seus complexos e completos processos, tratam as pessoas como executores de tarefas definidas em caixinhas.


Construção é projeto

abril 29, 2008

Escrevi uma tradução de um fragmento do livro “Software Project Secrets: Why Software Projects Fail”. Este trecho retrata bem a má interpretação que é feita do processo de desenvolvimento de software.

Construção é projeto

A construção de estradas consiste em uma sequência de fases bem definidas. O primeiro passo é planejar e projetar, o que resulta em um conjunto de planos e projetos (blueprints) que podem ser assinados. Uma vez que essas tarefas sejam concluídas a construção pode começar. A fase de construção consiste principalmente de tarefas bem definidas e repetitivas que podem ser executadas por empregados menos qualificados.
Ao contrário, o desenvolvimento de software é um processo de pesquisa, portanto em nenhum momento pode-se ter planos definitivos. Quanto mais definitivo tenta-se fazer os planos, mais falhos eles serão, e mais trabalho se terá ao revisá-los para que cumpram as mudanças de circunstâncias. Como a forma do sistema fica incrementalmente mais clara durante o curso do projeto, seu projeto (design) deve ser revisado constantemente. Reprojetar (redesign) a solução completamente de tempos em tempos pode ser custoso e desnecessário, portanto devemos pensar o projeto como um processo de design constante.
Sabemos que o trabalho repetitivo no desenvolvimento de software é rapidamente automatizado. Não existe nenhuma tarefa repetitiva a definir. Mas se as tarefas não são repetitivas, definí-las exaustivamente se torna um processo muito custoso em tempo. Ganha-se muito pouco definindo as tarefas dessa maneira. Software é abstrato, portanto definir as tarefas da construção completamente é equivalente a realizar o trabalho, pois existem ferrametas automatizadas que conseguem transformar estas definições em código.
Se as tarefas não podem ser bem definidas, então não podemos separar claramente as fases de design (projeto) e construção. Aliás, não existe fase de construção; o que existe é design (projeto) em escalas cada vez menores (níveis cada vez mais baixos). Isso significa que não podemos facilmente categorizar as pessoas nos papéis de arquitetos, projetistas (designers), programadores ou analistas. Estes papéis se sobrepoem. Todos os desenvolvedores têm o mesmo tipo de tarefas a fazer, apesar de uns terem mais responsabilidades que outros.
Quando um desenvolvedor cria uma nova funcionalidade num pedaço de software, a sua tarefa é simplesmente responder a seguinte pergunta “Essa funcionalidade irá funcionar exatamente como?”. Ele adiciona um conjunto de instruções ao código fonte que definem cada detalhe de como a funcionalidade funcionará. Porém, cada detalhe é uma decisão de projeto. Por exemplo, um fragmento de texto pode ser armazenado em um objeto imutável para uma maior eficiência, ou em um objeto mutável para maior flexibilidade. A escolha de uma dessas opções depende de como o texto será utilizado. É uma decisão bem significante.
Programar é mais do que apenas escrever código. Cada passo requer que o desenvolvedor analise uma parte do problema e projete uma parte da solução.

NOTA: Diferentemente de outros produtos, software não é construído, é projetado até a sua existência.

Acho que esse é um dos pontos em que as metodologias ágeis acertam e o RUP e os processos tradicionais falham. É um erro absurdo tratar a construção como uma tarefa repetitiva (tradução de diagramas para código fonte) que pode ser executada por empregados mais baratos (codificadores, programadores).
Como escutei lá no FISL, o movimento ágil é legal e funciona porque foi feito por programador para programador. É coisa de nerd mesmo!


É melhor disciplinar ou elogiar?

abril 16, 2008

Do livro Happy Hour is 9 to 5 de Alexander Kjerulf:

Qual destas filosofias tu achas que faz as pessoas mais felizes no trabalho?

  • Pegar as pessoas cometendo erros e puni-las imediatamente?
  • ou

  • Pegar as pessoas cometendo acertos e elogiá-las imediatamente?

Eu concordo com o autor e acredito que a segunda é muito mais eficiente. Aliás, esse livro contém várias dicas úteis para quem quer criar um bom ambiente de trabalho.
Vale a leitura!


Processos e confiança

abril 11, 2008

O processo de desenvolvimento de sw reflete totalmente a maneira como a empresa é administrada e como esta se relaciona com as pessoas.
Achei um artigo que compara alguns aspectos dos processos baseados no CMMI com os processos ágeis. Achei muito interessante a discussão sobre confiança.

The heart of the conversation was on the perception that if a model forces us to write something down then we are not trusted (the more we write stuff down, the less we trust one another).

Me parece ser bem adequada a colocação do autor, uma vez que um dos objetivos de toda a documentação que o CMMI impõe é a independência da empresa em relação às pessoas. Esse objetivo reflete de maneira muito clara a falta de confiança nas pessoas.