Bu dokümanın hazırlanmasında base aldığım dokümanın sahibi ve bu konuları anlamamda bana çok emeği geçen kişi Arman Altuğ ÖZHAN‘dır. 
Canı gönülden teşekkürlerimi sunuyorum.

 

Bu doküman Java EE teknolojileri kullanılarak ADF ile proje geliştirebilmek üzerine daha çok persistence ve control katmanı konusunda bilgiler içermektedir. Çok katmanlı mimari göz önüne alınarak tasarlanan sistem göz önüne alınmıştır. ADF teknolojisinin business (EO xml leri ve VO lar) modeli kullanılmadan ADF projelerinin geliştirilebilmesi açıklanmıştır.

Model katmanı

Bu bölüm genellikle EJB3.0 ve buna bağlı olarak geliştirilmiş tekrar kullanılabilir objeler ile sağlanan alt yapı kullanılarak proje geliştirme aşamalarının üzerinden geçmektedir.

Üzerinden geçilecek başlıklar:

1. Entity Beanler

2. Filtreler

3. DAO Objeleri

4. Exceptionlar

5. Session Beanler

Entity Beanler, veri kaynağındaki objeleri tanımlamak için kullanılırlar. Projedeki objeleri temsil ederler.

Filtreler, entity beanlere bağlı olarak üzerlerinde sorgu oluşturmak için kullandığımız objelerdir. sorgulanacak her bir entity objesine bir filtre hazırlanması gerekir.

DAO Objeleri, veri erişim kodlarının business kodları arasına yazılıp da kodu daha kompleks ve az anlaşılır hale getirmemesi için yaratılan tekrar kullanılabilir kod katmanlarıdır.

Exceptionlar, projenin beklenen çalışma düzeninden saptığında ortaya çıkan istinai durumlardır. Projede client ve server olmak üzere iki ana başlıkta toplanmıştır.

Session Beanler, projede yapılan işleri temsil ederler ve business kodlarının bulunduğu kod katmanlarıdır. Proje boyunca yapılacak ana işler bu katmanda gerçekleşir. Burada geliştirilen kodların anlaşılır olmasına ayrıca önem verilmelidir.

Entity Beans

Entity Bean objeleri önceki EJB versiyonlarında olduğu gibi verinin saklanacağı kaynak ile ilişkilendirilmesi için kullanılmaktadır. EJB3.0 versiyonlarında annotationların kullanılmaya başlanmasıyla ve veri kaynağının çeşitli veri kaynakları yerine veritabanı ile ilişkilendirilmesi ile daha anlaşılır ve daha kolay uygulanabilir bir hale gelmiştir.

Entity Beanler bildiğimiz basit java bean objelerinin bir türevidir. Annotationlar kullanılarak veri kaynağı ile java beanler ilişkilendirilir ve Object to Relational Mapping yapısı sağlanmış olur. Hibernate ORM (Object Relaional Mapping) tool kullanılarak bu entity’ler ve ilgili varlıklar veritabanı üzerinde otomatik olarak oluşturulması sağlanabilmektedir.

Projede geliştirme yaparken entity beanlerimizi, com.acme.proje_adı.modül_adı.entity paketi altında konumlandırmaktayız.

SuperEntity

BaseEntity ve BaseEntityView class ları tarafından extend edilen soyut bir sınıftır. Entity lerde kullanılan en temel ve genel methodları barındırır. @MappedSuperClass annotation ı ile işaretlenmiştir.

BaseEntityView

Geliştireceğimiz uygulamada entity objemiz, uygulamamız tarafından yönetilmeyecek oluşturulmayacak bir view yada tablo ise yani yalnızca bilgi okuyacaksak bu tür entity beanler BaşeEntityView objesinden türetilecektir. Böylelikle türetilen objenin serializable olmasının sağlanmasının yanı sıra objenin içerisindeki alt yapı için gerekli olan id, version ve entityName değişkenleri de otomatik olarak kullanması sağlanacaktır.

BaseEntity

Geliştireceğimiz ve uygulama tarafından okunup yazılacak(CRUD işlemlerinin tümü) entity beanler BaseEntity objesinden türetilecektir. Böylelikle türetilen objenin serializable olmasının sağlanmasının yanı sıra objenin içerisindeki alt yapı için gerekli olan id, version ve entityName değişkenleri de otomatik olarak kullanması sağlanacaktır. @MappedSuperClass annotation ı ile işaretlenmiştir.

İlk Entity Bean

Entity Bean’i geliştirirken öncelikle java bean’imizi Entity Bean olarak belirten @Entity annotationini kullanmalıyız. Entity annotationin bir özelliği olarak name alanını kullanmamız özellikle önemlidir. çünkü daha sonradan kullanılacak entityleri çağırırken bu isim kullanılacaktır. Örneğin EJB/QL(yada HQL) içerisinde kullanılacak entity adını bu alan belirlemektedir. Boş bırakıldığı takdirde class ismi bu ad yerine varsayılan olarak kullanılacaktır. Projede kullanışlılığı açısından Class ismini name özelliği olarak kullanacağız.

Entity annotationından sonra veri kaynağındaki tablo adı ile ilişki kurmakta işimize yarayacak olan @Table annotationini kullanmamız gerekiyor. Bu alanın özelliği olarak tablo adını tanımlamamız gerekmektedir. Burada name için kullanılacak format büyük harfler ile (varsa-modül_kısa_adı+)entity_adı+çoğul_eki olacaktır. Örneğin entity class name:Company tablename:COMPANİES

Son olarak kullandığımız veritabanının veya alt yapının özelliklerine göre bize primary key alanı olarak kullanabileceğimiz otomatik olarak artan bir değer sunan generatorları tanımlamamız gerekmekte. Projede kullanılan veritabanı Oracle olduğundan dolayı otomatik id alan değerini sequence alt yapısını kullanarak sağlayacağız. Bunun için @SequenceGeneratör annotationini kullanacağız. Özellik olarak name ve sequenceName alanlarını tanımlamamız gerekiyor. Buradaki format hem name için hem sequenceName için büyük harf ile Entity_adı+çizgi+SEQ cümleciği olacaktır.

Eğer BaseEntityView kullanıyorsak ve kullanıma verilen datasource taki veri yapısında(table-view) belirli bir PK alanı yapısal olarak yok, birkaç alan birleştirilerek çıkartılabiliyorsa aşağıdaki gibi entity_classname_PK ismiyle bir class yaratılarak ilgili entity’de kullanılabilmektedir.

Bu tanımları yaptıktan sonra JavaBeanımızın parametresiz constructorini tanımlayacağız. Constructor içerisine entityName alanı yukarıda kullanılan @Entity ile aynı değeri taşıyacak şekilde verilmelidir. Ayrıca bir collection objesi varsa bu initialize edilmelidir.

Daha sonra Entity Beanımızın hangi özellikleri taşıyacağı belirlenmelidir. Örnek olarak çalışan birisi için sicil numarası, adı, soyadı gibi alanlar private olarak tanımlandıktan sonra bir IDE aracılığı ile getter ve setter metodları yaratılmalıdır. Getterların önce yaratılması birçok uygulama sunucusu için önemlidir. Çünkü annotationlar getter methodların üzerine yazılır. (field tanımlanan alanda da yazılabilmektedir)

Getter ve setter metodlarının tanımlanmasından sonra bu alanların özelliklerini belirtmek için tekrar annotationlar yardımı ile tanımlar yapmamız gerekmektedir. Veritabanında karşılığı bulunan her alan için @Column annotationini ve bunun name özelliğini doldurmamız gerekmektedir. Kullanılacak format büyük harfler ile alan_adı olmalıdır. Karşılığı olmayacak alan için ise @Transient annotation i kullanılmalıdır.

Özel Alanlar

Bazı alanlar kullanımları açısından diğerlerinden farklıdır. id alanları ve diğer entityler ile ilişki kurulan alanlar bu kapsama girerler.

Id Alani

Bir alanın primary key alanı olduğu @id annotationi ile belirtilir. @id annotationi başka bir özellik taşımaz. Bunun dışında bu alanın değerinin ne şekilde sağlandığını belirtmek için @GeneratedValue annotationi kullanılır. Bu annotatinin iki özelliği vardır. Birisi değerin ne şekilde yaratılacağını belirten strategy diğeri ise bu değeri yaratacak nesnenin belirten generatör’dir. id alanı diğer alanlar gibi @Column annotationini kullanmalıdır.

Relation Alanlari

Relation alanları bir fieldin diğer bir entity ile ilişkisini tanımlamakta kullanılır. En yaygın olanları aşağıda listelenmiştir.

Bkz => http://en.wikipedia.org/wiki/Cardinality_(data_modeling)

@OneToOne uni-bidirectional

@OneToMany uni-bidirectional

@ManyToOne uni (one-to-many bidirectional many-to-one bidirectional ile aynıdır)

@ManyToMany uni-bidirectional

Bu relationlar tanımlanırken öncelikle targetEntity ile ilişkinin kurulduğu diğer Entity classi belirtilir. Bunun dışında cascade ile entity üzerinde işlem yapıldığında diğer entitynin durumunun ne şekilde etkileneceği belirtilir. Ve son olarak fetch ile bu alanın değerinin diğer entity ile otomatik olarak doldurulup doldurulmayacağına karar verilir.

Ayrıca relation annotationlarının yanısıra diğer entity ile ilişkinin veritabanında hangi alanda tutulacağını tanımlamak için @JoinColumn kullanılır.

toString Metodu

tostring metodu ile objenin görünen değeri set edilir. Mesela çalışanların yapılacağı bir entity için return getName()+” “+getLastName() şeklinde bir tanımlama yapılabilir.

Filters

Filtreler bir entity objesine bağlı olarak çalışan ve dinamik olarak sorgu yapmaya yarayan objelerdir. Bu yüzden veri kaynağından sorgulama yapılmak istenen her bir entity objesi için buna bağlı olarak çalışabilecek bir filter objesi yaratılmalıdır.

Filtreler, *.model.filter paketi altında tutulurlar. isimlendirme formatı olarak kendisi ile ilişkilendirilen entity objesinin isminin sonuna Filter uzantısı getirilerek oluşturulur.

Filtre class ları BaseFilter objesinden türetilirler. BaseFilter constructor’ı object parametresi olarak ilişkilendirilen entity bean objesini alır. BaseFilterin sorgulama yaparken kullanılacak createQuery metodu ile sorgu oluşturulurken kullanılan isNüllOrEmpty metodu vardır. createQuery metodunda entitynin doldurulmuş alanları kontrol edilir ve bunlara göre sorgu oluşturulur.

DAO Layer

DAO katmanı session beanlerin veri kaynağı ile işlemlerini gerçekleştirdikleri katmandır. session bean içerisinde yazılan business kodları ile veritabanı erişim kodlarını birbirinden ayırmak için, daha doğrusu veri kaynağına erişim kodlarını isole edebilmek için bu kodların farklı katmanlarda tutulmaları gereklidir. Bu yüzden veritabanı ile yapılan işlemler bu katman üzerinde gerçekleştirilir.

Aşağıda veritabanı üzerinde çalıştırılan modül bağımsız metodların çalıştığı dao örneği görülebilir.

findByPrimaryKey id alanı atanmış herhangi bir entity objesinin veritabanından çağrılmasını sağlamaya yönelik bütün session bean objeleri tarafından kullanılabilecek bir örnektir.

Bir diğer örnek olarak getEntityList verilen entity türünden bütün objeleri veritabanından çağırarak bir collection objesinde toplar.

fındByFilter örneğinde ise verilen bir filter objesinden üretilen sorgu ve bu sorgu sonucu dönen entity objeleri business katmanına geri döndürülür.

Her modülün ortak olarak kullanabileceği metodlar için bir MainDAO objesinin yanısıra her modülün kendi işlemlerini gerçekleştirebileceği bir dao objesi bulunabilir. Örneğin EDYS projesinde ApplicationDao class ı listelerin dolmasını sağlayan, SP(StoredProcedure) çağıran metodları barındıran bir dao objesi olarak tüm Test Talep ve EDYS projelerinin istediği sorgulamaları yapmaktadır.

DAO objeleri *.model.dao paketi altinda konumlanmistir.

Exceptions

Exceptionlar program içerisinde normal çalışma akışı dışında meydana gelen durumlardır. Bu durumların elden geldiğince maksimum düzeyde kontrol edilmesi iyi bir uygulamanın özelliklerinden birisidir.

Session Beans

Entity beanler objeleri temsil ederken session beanler işlemleri temsil ederler. Bu işlemler genellikle entity beanler üzerinde yapılır. Örneğin kayıt, banka transferi, stoktan mal çıkarma gibi işlemler hep sessionbean kullanılarak yapılırlar. Her session beanın en az bir interface objesi bulunur. Bu obje sessionbean objesi ile iletişim kurmakta kullanılır. Bahsedilen interfaceler local ve remote olarak ikiye ayrılır. Local objeler aynı jvm üzerinden çağırılabilirken remote objeler dağıtılmış uygulamalarda kullanılırlar. Bu yüzden istemciler tarafından kullanılacak her metod bu interfacelerde tanımlanmalıdırlar.

Session beanler com.acme.model.sessionbean paketi altında bulunurlar.

Session bean tanımlanırken öncelikle session beanın tipi belirtilir. Projede kullanacağımız session bean türü stateless session beanlerdir. @Stateless annotationi beanımızın stateless olduğunu belirtmede kullanılır. Ayrıca veritabanı ile yapılacak transactionları containerin yönetmesini sağlamak için @TransactionManagement annotationi kullanılır ve tipi de CONTAiNER olarak belirtilir. Ayrıca performans ve log tutmak için alt yapı tarafından kullanılan interceptorlar da @Interceptors annotationi kullanılarak sessionbeane tanımlanır.

Bu tanımları yaptıktan sonra beane default erişim seviyesini de beanı geliştirmeye başlamadan önce verebiliriz. Bu seviye bütün metodlar için geçerli olacaktır.

Stateless session beanler ile ilgili önemli bir konuda adından da anlaşılabileceği gibi bu beanler client ile ilişkili durum bilgilerini tutmazlar. Bu yüzden işlem yaparken herhangi bir durumlarını scope’u metod dışında olan bir değişkende tutup kontrol etmek veri tutarsızlığına kadar giden sorunlara yol açabilecektir.

Session beanımızı geliştirirken ilk yapmamız gerekenlerden birisi ORM ile ilişkiyi yönetecek olan EntityManageri tanımlamaktır. Bu objeyi tanımlarken hangi persistence context(entity objelerini tutan alan) ile ilişkisi olacağını @PersistenceContext annotationi ile yapabiliriz. Bu annotationa özellik olarak ünitName tanımlanır ve buraya verilecek değer persistence.xml dosyası içerisinde bulunur.

Constructorda bean içerisinde ortak olarak kullanılacak daolar initialize edilir.

Interface te tanımlı metodlarda metoda girmeden önce @RolesAllowed ile yetki seviyesi rol bazında belirlenmelidir. Default olarak classta tanımlanan role geçerli olacaktır. Birden fazla role yetki verilebilir.

EntityManager ile transactional işlemler yapmadan önce veri tutarlılığı açısından EntityManager’in flush modu COMMiT olarak atanmalıdır.

Bilinmesi gereken bir diğer obje de serverResponse’ tur. serverResponse içerisinde hem data hem de client tarafından işlenebilecek kontrol edilmiş exceptionları barındıran bir sınıftır. Özellikle işlem yapıldığı takdirde uyarı çıkabilecek durumlarda kullanılmalıdır.

Bunlar;

• synchronizeEntities(GridData gridData) throws Exception

· refreshEntities(serverResponse response, Collection entityList)

• persistEntities(serverResponse response, Collection entityList)
• removeEntities(serverResponse response, Collection entityList)

synchronizeEntities client tarafında grid üzerinde tutulan datanın son halinin veritabanına yazılması için kullanılan metoddur. Grid içerisindeki data ile tek tek işlem yapar ve kontrol dahilinde olan bir exception oluştuğunda bunu response içerisine ekler ve diğer datalar üzerinde işlem yapmaya devam eder.

synchronizeEntities metodu kullanılırken dikkat edilmesi gereken bu metoda gönderilen griddeki dataların birbirleri ile bağlantısının ne şekilde olacağıdır. Örnek olarak grid self reference olan entity objelerini tutuyorsa veri tutarlılığı açısından kullanılan metod değiştirilmelidir.

refreshEntities metodu veritabanından son halleri çekilecek olan entitiylerin response objesi olarak geri döndürülmesi için kullanılan metoddur.

persistEntities ve removeEntities te refreshEntities metodu gibi entityList içerisinde bulunan entitylerin veritabanına kaydedilmesi ve silinmesi işlemlerini yaparlar ve yanıtları response objesinde tutarlar.

Development

EJB bean ler JNDİ üzerinden structure projesi altındaki ServiceLocator objesi ile çağrılır. JNDI a kaydolabilmesi için Model projesi içerisinde ilgili xml file da gerekli tanımlamalar yapılmalıdır.

Deployment kütüphanelerinin önceliği ise weblogic-application.xml dosyasında belirtilir.

Sıradan bir tanımlama ekranı geliştirirken izlenebilecek sıra şu şekilde olabilir.

• Server tarafında geliştirme yaparken öncelikle entitylerin tanımlanması mantıklı olur. Entityler hem server hem client tarafında kullanılacak temel objelerdir.

• Entity tanımlandıktan sonra eğer bu entity objesi üzerinde sorgulama yapılacaksa filtre tanımlanmalıdır.

• Bu işlemden sonra gerekli dao metodlarının tanımlanması gerekir. Bu adım her zaman gerekmeyebilir veya sessionbeanler geliştirilirken dao metodları aynı zamanda geliştirilebilir.

• Bu adımda exceptionların tanımlanması gerekir. Business exceptionlar yalnızca ve yalnızca sessionbeanler üzerinden atılmalıdır.

• Exceptionların ardından business işlemlerinin gerçekleştiği session beanlerin ve interfacelerin tanımlanması gelir. sessionbeanler yukarıda bahsedilen adımlarda geliştirilen tüm objeleri kullanabilirler bu yüzden en son veya 3. ve 4. adımla birlikte tanımlanmaları gerekir. session beanden önce interface objesinin tanımı yapılmalıdır. interface objesinin metodları önce session bean objesinde tanımlanır.

Business işlemleri gerçekleştirilirken ise

• Entity beanler genellikle önceden yaratılmış olacaktır.

• Filtre objeleri muhtemelen gerekmeyecektir veya önceden tanımlı olacaktır.

• Muhtemelen önceden hazırlanmış dao metodları kullanılacaktır(fındByPrimaryKey, fındByFilter gibi).

• Business işlemleri yapılırken oluşacak istisnai durumlar göz önüne alınıp bu durumlara uygun exceptionların oluşturulması gerekir.

• Business işlemleri gerçekleştirecek sessionbeanler ve interfaceleri hazırlanır. Gerekiyor ise weblogic-ejb-jar.xml dosyasına tanımlanırlar.

Bu işlemlerden sonra model projesi deploy edilmeye hazır hale gelmiş olacaktır.

Resources

Java uygulamalarında statik olarak hazırlanan textlerin yerel dillere çevrilmesi için kullanılan en yaygın metod resource bundleları kullanmaktır. Resource Bundle’lar bir anahtar sözcüğün karşılığı olarak bir obje döndüren dizilerdir.

Çoğu java uygulaması gibi bu uygulamada da bu iş için Resource Bundle’lar kullanılmaktadır. Altyapı ve her modül için ayrı birer resource bundle tanımlanmıştır. ResourceBundle’lar ListResourceBundle objesinden türemişlerdir.

Component etiketleri, exception tanımları, genel mesajlar(lütfen bekleyiniz, işlem başarılı veya konfirmasyon işlemleri gibi), veya modül bağımsız genel ekranlar(login, logout, şifre değişimi) gibi işlemler alt yapı için kullanılan resource bundle içinde tanımlanabilirler. Resource Bundle’lar; Resources projesi altindaki com.arsivist.resource.bundle paketi altinda bulundurulurlar.

İsimlendirme olarak da ResourceBundle+”_”+varsa-modul_adi+”_”+local_dil_kodu verilebilir.

ViewController projesi Geliştirme

Oracle ADF ile Web uygulamaları , masaüstü uygulamaları, mobil uygulamalar; JDeveloper geliştirme ortamının sunduğu deklaratif yöntemlerle ve görsel arayüz desteğiyle kolaylıkla oluşturulabiliyor.

Model: İş mantığı (Business Logic) bölümüdür. Tek katmandan oluşabileceği gibi, birden fazla katmanı da içinde barındırabilir. Tek katmandan oluştuğunda genelde veritabanına kayıt ekleme, kayıt çekme, kayıt silme vb. veritabanı işlemleri için kullanılır. Controller’den gelen değerleri işler ve geriye döndürür. Model katmanında herhangi bir –loglama haricinde- output işlemi yapılmaz.

View: Uygulamanın kullanıcıya gösterilen arayüzünün bulunduğu katmandır. Html, Css, Javascript, JSF vb. bu katmanda bulunur.

Controller: Uygulamanın karar mekanizmasıdır. Model ile View arasında köprü görevi görür.

İş Servisleri Katmanı: Bu katman farklı kaynaklardaki veriye erişimin sağlandığı ve iş mantığının tanımlandığı katmandır.

Bu katmanların tümünde, Oracle ADF istenilen teknolojinin kullanılmasına olanak sağlar. EJB, örneğin iş servisleri katmanında Web servisleri, JavaBeans, JPA, Hibernate kullanılabilirken, View katmanında, JSF, JSP, ADF Faces kullanılabilir. Sektördeki uygulama sunucularından biri olan WebLogic JDeveloper ile entegre olarak paketlenmiş halde gelmektedir. JDeveloper ve ADF ile uygulamanızı geliştirirken, aynı anda WebLogic üzerinde test/debug yapılabilmektedir.

MVC tasarım deseni temel alan Oracle ADF framework unde UI tarafında JavaServerFaces standardının üstüne konumlandırılan ADFFaces kullanılarak UI bileşenleri tasarlanır, UI bileşenleriyle model tarafını konuşturan Contoller’lar (MBean classları) aynı projede geliştirilebilmektedir(ViewController projesi). MBean ler gibi java objeleri src nin altında *.vc.projectname hiyerarşisindeki gibi bir paket yapısıyla yer alırken html bileşenleri ve taşk-flow konfigürasyon dosyaları public_html klasörünün altında yer bulur.

Basit bir fonksiyonel ekran düşünelim. Önyüzde son kullanıcıya bazı UI bileşenleri gösterilecek, girilen yada otomatik yüklenen bazı bilgilere göre kullanıcıya bazı bilgiler gösterilecek. Bu durumda öncelikle aklımıza hangi bilgilerin ne şekilde getirilerek gösterileceği aklımıza gelmektedir. Veri kaynağını sağlayacak business service bir webservisi, web’e açık bir api, bir ADFBC datacontrol bileşeni, EJB nesnesi olabilir. Bu service nesneleri, veritabanından, BPM’den yada yalnızca memorydeki bir pojo objesinden veri getiriyor olabilir. Veri getirilen katman ve kontrolörleri model katmanı olarak düşünebiliriz. Bu kısmı tamamladığımızı düşünürsek ön tarafta kullanıcının neleri nasıl göreceğini ve nasıl kontrol edeceğini düşünmeye geçeriz. Bu aşamadaki çözüm Controller katmanıdır; ADF frameworkundeki karşılığı ise taskflowlar olabilmektedir.

Task-flow da kullanılacak (ManagedBean)MBean ler task-flow larda tanımlanarak on yüzden tetiklenmesi yada önyüzü oluşturulması sağlanır. MBean ler ise Model projesi ve diğer util projelerine ulaşarak task-flow un ihtiyaç duyduğu verileri kaydedip sağlayarak hizmet verir, WebService çağırarak süreç tetikler, UCM den doküman çeker yada revizyonlar… Contoller objeleri; View katmanından gelen istekleri(request) model’e gönderir ve Model katmanından aldığı verileri view’e aktarır.

Oluşturulan task-flow yapısı xml dosyaları ile file systemde tutulmaktadır. Task-flow bileşenlerine özgü bileşen palette inden view bileşenini eklersek. Bu bileşenin karşılığı olarak bir web sayfası(jsp, jspx, jsf, jsff) yaratacağız demektir. Sayfaya, ihtiyacımız olan UI bileşenlerini ekleyerek task-flowda tanımladığımız MBean class ındaki ilgili metotlarla bağlantısını kurarız(binding). Task-flow üzerinde tanımlanan sayfa ve metot çağrımları sırasında ise veri geçişlerini çağıracak parametre leri tanımlarız.

Uygulamayı portal uygulaması olarak planladıysak oluşturulan task -flow lar bir jspx dosyasına atılarak geliştirme sırasında integrated weblogic sunucusu üzerinde çalışması gözlemlenir. Her bir ön yüz bileşeni esasında jsff fragment i olarak tasarlanabilmektedir. Her bir fragment ise istenilen –yapısına uygun olmak koşulu ile- bir task-flow içerisinde bir view bileşenine denk gelecek biçimde kullanılabilmektedir.