Documente Academic
Documente Profesional
Documente Cultură
- Iconix
R
Pgina 1
Processos
R
Pgina 2
Processos
R
Pgina 3
R
Pgina 4
ICONIX
O Iconix define-se como um processo de desenvolvimento de software prtico, algures entre a complexidade e abrangncia do Rational Unified Process (RUP) e a simplicidade e o pragmatismo do Extreme Programming (XP). O Iconix conduzido por casos de utilizao, iterativo e incremental, tal como o RUP, mas sem a complexidade que este preconiza. Por outro lado, relativamente pequeno e simples, tal como o XP, mas sem eliminar as tarefas de anlise e de desenho que aquele no contempla. Por fim o Iconix usa o UML como linguagem de modelao e apresenta um alto grau de rastreabilidade.
Pgina 5
Anlise de Sistemas Engenharia Informtica e das Tecnologias da Informao / Engenharia Informtica/ Informtica para a Sade/ Tecnologias da Informao e Multimdia
O Processo da ICONIX
O ICONIX uma metodologia de desenvolvimento de software promovida pela empresa ICONIX Software Engineering http://www.iconixsw.com/ O ICONIX define-se como um Processo de desenvolvimento de software prtico e pertence classe dos light weight methods, ou metodologias geis.
O ICONIX conduzido pelos casos de utilizao (use cases), e iterativo e incremental, tal como o RUP, mas bem menos complexo. O ICONIX utiliza o UML como linguagem de modelao e apresenta um alto grau de rastreabilidade (traceability)
Rastreabilidade: capacidade de se seguirem as vrias relaes entre os diferentes artefactos no processo de desenvolvimento, de forma a conseguir-se, por exemplo, averiguar o impacto que uma determinada alterao de um requisito tem em todos os restantes artefactos (modelos de anlise, projecto, e implementao).
R
Pgina 6
Viso Geral
A metodologia consiste na produo de um conjunto de artefactos que retractam as vistas dinmicas e estticas de um sistema, e que vo sendo desenvolvidos incrementalmente e em paralelo A figura seguinte ilustra a viso geral do ICONIX.
Esta figura revela um aspecto importante da utilizao do UML: o facto de um sistema apenas depender da verso detalhada do diagrama de classes final (parece bvio, mas muitos indivduos pensam ainda que se poderiam usar, por exemplo, diagramas de sequncia para gerar cdigo automaticamente!).
R
Pgina 7
Viso Geral
Dinmica
System
Object1 Object2 Object3
UseCase3
Prototype GUI
* * * Actor1
< B a ck N ex t > Can c el
Actor2
Message1 Message1
* * *
UseCase2
Message1
Message1
UseCase1
Message1
Message1
Diag. Sequncia
Evento
RegistaEvento BotoOK
RegistaEvento Pgina
UDocente
CriaEvento
Diag. Robustez
RegistaEvento BotoConsulta
Consultar Eventos
Esttica
Class1 Class1 1 * Class1
Cdigo
Class1 Class1 Class1 Class1
Diag. Classes
R
Pgina 8
Anlise de Requisitos
Identificar os objectos do mundo real e todas as relaes de generalizao, associaes e agregao entre esses objectos. Desenhar o correspondente diagrama de classes de alto nvel, designado por modelo de domnio.
Se for razovel, desenvolver prottipos de interface homemmquina (GUI), diagramas de navegao, etc., de forma a que os utilizadores e clientes entendam melhor o sistema pretendido.
Identificar os casos de utilizao envolvidos no sistema. Desenhar os diagramas de casos de uso realando os actores envolvidos e as suas relaes. Organizar em grupos os casos de utilizao. Capturar essa organizao em pacotes. Associar requisitos funcionais aos casos de utilizao e aos objectos de domnio.
R
Pgina 9
Anlise de Requisitos
Dinmica
System
Object1 Object2 Object3
UseCase3
Prototype GUI
Actor2
* * Actor1
< Back Next > Cancel
Message1 Message1
* * * *
UseCase2
Message1
Message1
UseCase1
Message1
Message1
Diag. Sequncia
RegistaEvento BotoOK
Evento
RegistaEvento Pgina
UDocente
CriaEvento
Diag. Robustez
RegistaEvento BotoConsulta
Consultar Eventos
Class1
Esttica
Class1 1 * Class1
Cdigo
Class1 Class1
Class1 Class1
Diag. Classes
R
Pgina 10
Anlise de Requisitos
O ICONIX distingue explicitamente um requisito de um caso de uso. Em particular, o seu autor distingue-os da seguinte forma:
descreve
uma regra
uma
que
unidade
governa
de
o
Ento, segundo o ICONIX, existe uma relao de n para n entre casos de uso e requisitos, pelo que tem sentido a ultima actividade desta tarefa, que associa estes dois conceitos. Outros autores defendem que os casos de uso so o mecanismo ideal para especificar os prprios requisitos de um sistema.
R
Pgina 11
Fazer as descries dos casos de utilizao com os cenrios principais, cenrios alternativos e cenrios de excepes. Fazer a anlise de robustez. Para cada caso de uso:
Identificar os primeiro objectos. Usar os esteretipos de classes definidos no perfil processos de desenvolvimento de software especificados no UML 1.3 (<<boundary>>, <<control>> e <<entity>>) Actualizar o diagrama de classes do modelo do domnio, com os novos objectos e atributos, entretanto descobertos.
R
Pgina 12
* * * Actor1
< B ack N ext > Cancel
Actor2
Message1 Message1
* * *
UseCase2
Message1
Message1
UseCase1
Message1
Message1
Diag. Sequncia
Evento
RegistaEvento BotoOK
RegistaEvento Pgina
UDocente
CriaEvento
Diag. Robustez
RegistaEvento BotoConsul ta
Consultar Eventos
Class1
Esttica
Class1 1 * Class1
Cdigo
Class1 Class1
Class1 Class1
Diag. Classes
R
Pgina 13
Projecto (Design)
Terminar o modelo esttico, adicionando informao detalhada sobre o desenho (e.g. visibilidade e padres de desenho). Verificar se o desenho satisfaz todos os requisitos identificados.
R
Pgina 14
Projecto
Dinmica
System
UseCase3
Prototype GUI Object1 Object2 Object3
* * Actor1
< B ack N ext > Cancel
Actor2
Message1 Message1
* * * *
UseCase2
Message1
Message1
UseCase1
Message1
Message1
Diag. Sequncia
Evento
RegistaEvento BotoOK
RegistaEvento Pgina
UDocente
CriaEvento
Diag. Robustez
RegistaEvento BotoConsul ta
Consultar Eventos
Class1
Esttica
Class1 1 * Class1
Cdigo
Class1 Class1
Class1
Class1
Diag. Classes
R
Pgina 15
Implementao
Consoante as necessidades, produzir diagramas de arquitectura, diagramas de instalao e de componentes, que apoiem a tarefa de implementao. Escrever e, eventualmente, gerar cdigo.
Realizar teste unitrios e de integrao Realizar testes de sistema e de aceitao
R
Pgina 16
Implementao
Dinmica
System
Object1 Object2 Object3
UseCase3
Prototype GUI Actor2
* * Actor1
< B ack N ext > Cancel
Message1 Message1
* * * *
UseCase2
Message1
Message1
UseCase1
Message1
Message1
Diag. Sequncia
Evento
RegistaEvento BotoOK
Diag. Robustez
RegistaEvento BotoConsul ta
Consultar Eventos
Class1
Esttica
Class1 1 * Class1
Cdigo
Class1 Class1 Class1 Class1
Diag. Classes
R
Pgina 17
O ICONIX lana um conjunto de avisos relativamente a problemas e dvidas comuns, que devero se levados em conta pelos intervenientes do processo. Os avisos relacionados com a realizao da tarefa de anlise de requisitos tm como principal objectivo evitar a perda de tempo com detalhes desnecessrios, designadamente: Na produo dos modelos de domnio: No perder demasiado tempo com a inspeco gramatical. No enderear o desenho da multiplicidade demasiado cedo no projecto. Enderear a agregao e composio apenas na fase de projecto detalhado Na produo dos modelos de casos de utilizao: No comear a escrever os casos de uso at se conhecer bem como os utilizadores vo actuar No passar semanas a construir modelos de casos de utilizao elaborados e bem desenhados, mas a partir dos quais no possvel construir-se um adequado desenho de classes. No perder muito tempo em discusses sobre quando e onde usar relaes include ou extend. No usar templates textuais de casos de uso muito longos ou muito complexos.
R
Pgina 18
Avisos a ter em conta na realizao da tarefa de anlise e desenho preliminar: No procurar fazer desenho detalhado nos diagramas de robustez. No perder tempo a tentar aperfeioar os diagramas de robustez medida que o desenho evolui. Avisos a ter em conta na realizao da tarefa de projecto (desenho): Na produo de diagramas de sequncia No procurar associar comportamento aos objectos antes de se ter uma ideia concreta sobre o seu significado e interesse para o sistema. No comear a desenhar um diagrama de sequncia antes de se ter completado o diagrama de robustez correspondente. No focar a ateno (e esforo) na definio de mtodos get e set em detrimento dos mtodos reais Na produo dos diagramas de estado: No desenhar diagramas de estado para objectos com apenas dois estados No modelar o que no necessrio modelar. No desenhar diagramas de estados s por se consegue desenh-los.
R
Pgina 19
Diagramas de Robustez
A anlise de robustez uma actividade importante do ICONIX. Este tipo de actividade foi inicialmente proposto por Ivar Jacobson, de forma a permitir ilustrar graficamente as interaces entre os objectos participantes num caso de utilizao. Foram definidos trs tipos de objectos, que se encontram definidos no perfil Processos de Desenvolvimento de Software especificados no UML 1.3. Objectos de fronteira/interface (<<boudary>>), permitem aos actores comunicarem com o sistema. Exemplos comuns deste tipo de objectos so janelas, ecrs, pginas web, janelas de dilogo, etc.. Objectos de entidade (<<entity>>), correspondem geralmente aos objectos identificados no modelo de domnio. Estes objectos so geralmente mapeados em tabelas de bases de dados ou ficheiros que guardam a informao necessria.
R
Pgina 20
Diagramas de Robustez
Objecto Fronteira
Objecto Entidade
Objecto Controlo
Objectos de controlo (<<control>>), funcionam como integradores entre os objectos de fronteira e os objectos de entidade. O objectivo destes objectos conterem as regras de negcio e as polticas de funcionamento de modo a potenciarem a independncia das interfaces com os utilizadores, por um lado, e dos esquemas das bases de dados, por outro. Estes objectos terminam ocasionalmente como objectos no modelo esttico; mas mais geralmente, acabam por ser convertidos em mtodos de objectos de entidade ou de objectos de fronteira.
R
Pgina 21
Diagramas de Robustez
A anlise de robustez desempenha no ICONIX um papel charneira na passagem entre a anlise (o qu) e o desenho (projecto) (o como). Tendo as seguintes funes principais. Teste de razoabilidade: permite validar se a descrio textual de um use case tem sentido e se a especificao do comportamento do sistema razovel, dado o conjunto de objectos identificados. Teste de completude: permite validar se todos os cursos de execuo de um sistema so descrito atravs de use cases Descoberta de objectos: permite identificar novos objectos que no foram descobertos anteriormente durante a modelao de domnio. Uma sugesto do ICONIX desenvolver os diagramas de anlise de robustez antes, ou em paralelo, com a descrio textual dos casos de uso, de modo a influenciar a identificao dos objectos intervenientes e a escolha dos nomes usados. A ideia geral que os nomes genricos devero ser substitudos por nomes de objectos que aparecem nos diagramas de robustez. Outra sugesto relevante evitar fazer desenho detalhado nesta fase e nestes diagramas. O seu principal objectivo captar, para cada use case, os principais objectos e respectivas relaes de comunicao.
R
Pgina 22
Diagramas de Robustez
O ICONIX preconiza um conjunto de regras para auxiliar o desenho de diagramas de robustez, em particular so definidas as seguintes regras
Os actores podem comunicar com o sistema atravs de objectos fronteira. Os objectos fronteira comunicam apenas com os actores e objectos de controlo
Actor3
Actor3
Permitido
No Permitido
R
Pgina 23
Diagramas de Robustez
Apresenta-se na figura, a ttulo de exemplo, o diagrama de robustez relativo ao caso de utilizao Registar evento.
Note-se que as interaces entre os diferentes tipos de objectos, que traduzem em termos gerais o comportamento deste caso. Observem-se ainda as relaes de agregao entre a pgina de registo de eventos e os seus respectivos botes
ValidaEvento
RegistaEvento BotoOK
Evento
RegistaEvento Pgina
UDocente
CriaEvento
Consultar Eventos
RegistaEvento BotoConsulta
R
Pgina 24