30.05.2008
23.05.2008
C# ve Java ile sistemi istenen süre boyunca uyutma
C#
System.Threading.Thread.Sleep(75);
Java
java.lang.Thread.sleep(75);
C/C++
delay(75);
// verilen parametre milisaniye cinsinden
// 1000 ms=1 saniye .
System.Threading.Thread.Sleep(75);
Java
java.lang.Thread.sleep(75);
C/C++
delay(75);
// verilen parametre milisaniye cinsinden
// 1000 ms=1 saniye .
21.05.2008
Yazılımı Tasarlamak
bir önceki makalenin devamı olarak gelen bu makalede eğer hah işte şimdi kodlama kısmı gelecek diyorsanız yanılıyorsunuz. çünkü hala yapacak çok işimiz var.
Yazılımda Tasarım
Bir önceki Yazılım Geliştirme ve Analiz (Yazılım , sadece kodlardan mı oluşur ? ) yazısını okumadıysanız mutlaka okumanızı öneririm. Çünkü bu yazı tamamen orada oluşturduğumuz zemin üzerine bir yazı olacaktır.
Yazılım geliştirmede analiz süreciyle yapılan şey “problemi tanımlamak”tır. Sonrasında gelecek olan adımsa, analizden ve müşterinin performans beklentisi, teknolojiye yakınlığı, bütçesi, fiziksel şartları vb. koşullara bakılarak en uygun çözümün belirlenmesidir. Bu aşama, müşterinin isteklerinin hangi tür donanım, işletim sistemi, ağ sistemi, yazılım dil ve teknolojileri kullanarak yapılacağını belirleyeceğimiz aşama olacaktır. Şimdi yavaş yavaş başlayalım tasarımımıza…
İlk olarak analizden müşterinin yazılım hakkındaki beklentilerini toparlamaya çalışalım.
1. Uygulama bir web uygulaması olacaktır.
2. Uygulamanın arka tarafında verileri saklamak için bir veritabanı kullanılacaktır.
3. Uygulama bir SMS servisi aracılığıyla mesaj gönderecektir.
Uygulama bir web uygulaması olacaksa, yazılımımız ve veritabanı bir web sunucusu üzerine yüklenecek demektir. Bu durumda diyetisyen ve sekreteri de aynı web uygulaması üzerinden sisteme erişerek işlevlerini yürütmek durumundadırlar. Toplamda bir önceki girdide proje şartnamesi için çıkarttığımız listedeki tüm işlevleri bir web uygulamasıyla yerine getirmek mümkündür. Bu durumda analizimizin doğruluğunu sınamış olduk ve tasarım aşamasında konsepti çatısını da belirledik:
“Önde bir web arayüzüyle arka tarafta ilişkisel veritabanıyla çalışacak olan bir sistem geliştirilecektir.”
Şimdi kullanılacak teknoloji ve araçları belirleyelim. İlk olarak müşterinin mevcut bir web hostingi olduğu için buradaki teknolojiyi öğrenmemiz gerekir. Diyelim ki müşterinin web sitesi Asp.Net ve MS Sql destekliyor. O zaman yapmamız gereken web uygulamasını Asp.Net ile kodlayıp veritabanı olarak da MS Sql üzerine tablolarımızı oluşturmak olmalıdır. Bu arada eğer müşterinin özellikle bir teknoloji talebi varsa bunu da dikkate almanız gerekecektir. Örneğin bizim diyetisyen amatör olarak Visual Basic ile ilgileniyor ve kodlamada dil olarak Visual Basic’i tercih etmemizi istiyor olabilir.
Evet, sonuç olarak teknoloji ve araç seçimimizi listeleyecek olursak:
1. Web uygulama tarafı Asp.Net kullanılarak geliştirilecektir.
2. Veritabanı MS Sql 2005 olacaktır.
3. Programlama dili olarak Visual Basic 9 kullanılacaktır.
Yukarıdaki maddeler için müşterinin onayını aldıktan sonraki adım tasarımı detaylandırma aşamasıdır. Teknoloji belli olduğuna göre şimdi analizi önümüze alıp arayüzleri kâğıt üzerinde karalamak (taslak olarak) , önemli fonksiyonları belirlemek ve veritabanı tablo ve tablolar arası ilişkileri belirlemek olacaktır. Bu aşama hem analizimizi detaylı olarak doğrulamamızı sağlar hem de yazılımı geliştirmeye başlamadan önce yazılım bitince ortaya ne çıkacağı yönünde hem müşteriye hem de bize ipucu verir.
Tasarımı detaylandırırken ilk olarak hastaların sisteme güvenli girişini atladığımız fark ediyoruz. Hastalar randevu alırken bazı bilgiler giriyorlar ama öncesinde sisteme güvenli girişleri atlanmış durumda. Yani şu an benim cep telefonu numaramı bilen herkes benim randevu durumumu görebilir ya da benim yerime gidip randevumu iptal edebilir. Diyetisyen ve sekreter için bir giriş paneli var ama hastalar için yok. Hemen bir çözüm iletip diyetisyene sunuyoruz…
Hastalarınız için sisteme güvenli bir giriş ortamı sağlamamız gerekiyor. Bunun için çözüme 4 ekran daha eklememiz gerekiyor. Bunların üçü hastalar için; hasta ilk kayıt ekranı, hasta giriş ekranı ve hasta parola değiştirme ekranı. Bir tanesi de sizin tarafınızdan yönetilecek (sekreter de olabilir) hasta parola sıfırlama ekranı. Hastalar parolalarını unutursalar diye…
Diyetisyenimiz önerimizi onayladı. Şimdi son eksiği tamamlayalım: listeler ve raporlar…
Diyetisyenin, sekreterin ve hastaların sistemden bekledikleri liste ve raporları bilmemiz gerekiyor. Liste ve raporları hem liste ve rapor ekranlarını tasarlamak için hem de tablo ve tablo alanlarımızın doğruluğunu kontrol ederken kullanacağız. Bu noktada liste ve raporların neler olacağını, bunların hangi bilgileri içereceğini ve bilgileri nasıl, hangi biçimde göstermesi gerektiğini sekreter ve diyetisyenden isteyeceğiz. Onlar bu bilgileri hazırlarken biz de elimizdeki bilgilerle web arayüzlerini ve tablo tasarımlarını oluşturmaya başlayacağız.
İlk olarak ekranları tasarlayalım. Her bir ekran için öncelikle ekranı taslak olarak çizip (bir A4 kağıdına kurşun kalemle bile olabilir) ekranı kimlerin kullanacağını, ekranda işleyişin nasıl olacağını, ekran kullanılırken oluşacak istisnai durumlar için neler yapılacağını belirten bir doküman hazırlamalıyız.
tasarı için gerekli resimler ve devamı için kaynak: http://www.chip.com.tr/blog/kadircamoglu/Yazilimda-Tasarim_950.html
not: demekki ne yapıyormuşuz " dereyi görmeden paçaları sıvamıyor muşuz" . daha ne yapacağımızı bilmeden nereye öyle kod yazıyoruz dimi ya ....
Yazılımda Tasarım
Bir önceki Yazılım Geliştirme ve Analiz (Yazılım , sadece kodlardan mı oluşur ? ) yazısını okumadıysanız mutlaka okumanızı öneririm. Çünkü bu yazı tamamen orada oluşturduğumuz zemin üzerine bir yazı olacaktır.
Yazılım geliştirmede analiz süreciyle yapılan şey “problemi tanımlamak”tır. Sonrasında gelecek olan adımsa, analizden ve müşterinin performans beklentisi, teknolojiye yakınlığı, bütçesi, fiziksel şartları vb. koşullara bakılarak en uygun çözümün belirlenmesidir. Bu aşama, müşterinin isteklerinin hangi tür donanım, işletim sistemi, ağ sistemi, yazılım dil ve teknolojileri kullanarak yapılacağını belirleyeceğimiz aşama olacaktır. Şimdi yavaş yavaş başlayalım tasarımımıza…
İlk olarak analizden müşterinin yazılım hakkındaki beklentilerini toparlamaya çalışalım.
1. Uygulama bir web uygulaması olacaktır.
2. Uygulamanın arka tarafında verileri saklamak için bir veritabanı kullanılacaktır.
3. Uygulama bir SMS servisi aracılığıyla mesaj gönderecektir.
Uygulama bir web uygulaması olacaksa, yazılımımız ve veritabanı bir web sunucusu üzerine yüklenecek demektir. Bu durumda diyetisyen ve sekreteri de aynı web uygulaması üzerinden sisteme erişerek işlevlerini yürütmek durumundadırlar. Toplamda bir önceki girdide proje şartnamesi için çıkarttığımız listedeki tüm işlevleri bir web uygulamasıyla yerine getirmek mümkündür. Bu durumda analizimizin doğruluğunu sınamış olduk ve tasarım aşamasında konsepti çatısını da belirledik:
“Önde bir web arayüzüyle arka tarafta ilişkisel veritabanıyla çalışacak olan bir sistem geliştirilecektir.”
Şimdi kullanılacak teknoloji ve araçları belirleyelim. İlk olarak müşterinin mevcut bir web hostingi olduğu için buradaki teknolojiyi öğrenmemiz gerekir. Diyelim ki müşterinin web sitesi Asp.Net ve MS Sql destekliyor. O zaman yapmamız gereken web uygulamasını Asp.Net ile kodlayıp veritabanı olarak da MS Sql üzerine tablolarımızı oluşturmak olmalıdır. Bu arada eğer müşterinin özellikle bir teknoloji talebi varsa bunu da dikkate almanız gerekecektir. Örneğin bizim diyetisyen amatör olarak Visual Basic ile ilgileniyor ve kodlamada dil olarak Visual Basic’i tercih etmemizi istiyor olabilir.
Evet, sonuç olarak teknoloji ve araç seçimimizi listeleyecek olursak:
1. Web uygulama tarafı Asp.Net kullanılarak geliştirilecektir.
2. Veritabanı MS Sql 2005 olacaktır.
3. Programlama dili olarak Visual Basic 9 kullanılacaktır.
Yukarıdaki maddeler için müşterinin onayını aldıktan sonraki adım tasarımı detaylandırma aşamasıdır. Teknoloji belli olduğuna göre şimdi analizi önümüze alıp arayüzleri kâğıt üzerinde karalamak (taslak olarak) , önemli fonksiyonları belirlemek ve veritabanı tablo ve tablolar arası ilişkileri belirlemek olacaktır. Bu aşama hem analizimizi detaylı olarak doğrulamamızı sağlar hem de yazılımı geliştirmeye başlamadan önce yazılım bitince ortaya ne çıkacağı yönünde hem müşteriye hem de bize ipucu verir.
Tasarımı detaylandırırken ilk olarak hastaların sisteme güvenli girişini atladığımız fark ediyoruz. Hastalar randevu alırken bazı bilgiler giriyorlar ama öncesinde sisteme güvenli girişleri atlanmış durumda. Yani şu an benim cep telefonu numaramı bilen herkes benim randevu durumumu görebilir ya da benim yerime gidip randevumu iptal edebilir. Diyetisyen ve sekreter için bir giriş paneli var ama hastalar için yok. Hemen bir çözüm iletip diyetisyene sunuyoruz…
Hastalarınız için sisteme güvenli bir giriş ortamı sağlamamız gerekiyor. Bunun için çözüme 4 ekran daha eklememiz gerekiyor. Bunların üçü hastalar için; hasta ilk kayıt ekranı, hasta giriş ekranı ve hasta parola değiştirme ekranı. Bir tanesi de sizin tarafınızdan yönetilecek (sekreter de olabilir) hasta parola sıfırlama ekranı. Hastalar parolalarını unutursalar diye…
Diyetisyenimiz önerimizi onayladı. Şimdi son eksiği tamamlayalım: listeler ve raporlar…
Diyetisyenin, sekreterin ve hastaların sistemden bekledikleri liste ve raporları bilmemiz gerekiyor. Liste ve raporları hem liste ve rapor ekranlarını tasarlamak için hem de tablo ve tablo alanlarımızın doğruluğunu kontrol ederken kullanacağız. Bu noktada liste ve raporların neler olacağını, bunların hangi bilgileri içereceğini ve bilgileri nasıl, hangi biçimde göstermesi gerektiğini sekreter ve diyetisyenden isteyeceğiz. Onlar bu bilgileri hazırlarken biz de elimizdeki bilgilerle web arayüzlerini ve tablo tasarımlarını oluşturmaya başlayacağız.
İlk olarak ekranları tasarlayalım. Her bir ekran için öncelikle ekranı taslak olarak çizip (bir A4 kağıdına kurşun kalemle bile olabilir) ekranı kimlerin kullanacağını, ekranda işleyişin nasıl olacağını, ekran kullanılırken oluşacak istisnai durumlar için neler yapılacağını belirten bir doküman hazırlamalıyız.
tasarı için gerekli resimler ve devamı için kaynak: http://www.chip.com.tr/blog/kadircamoglu/Yazilimda-Tasarim_950.html
not: demekki ne yapıyormuşuz " dereyi görmeden paçaları sıvamıyor muşuz" . daha ne yapacağımızı bilmeden nereye öyle kod yazıyoruz dimi ya ....
Yazılım , sadece kodlardan mı oluşur ?
Yazılım , sadece kodlardan mı oluşur ? Bunun cevabını aşağıdaki makale çok güzel anlatmış.
Yazılım geliştirme sadece kodlamaktan ibaret değildir. Bir problemin çözümü olarak nitelediğimiz yazılımların ne yapacağını ve nasıl yapacağını belirlediğimiz yani problemi tanımladığımız aşama “Analiz” aşamasıdır. Yazdığınız kod ancak isteneni doğru bir biçimde yerine getiriyorsa başarılı bir yazılımdır. Bu nedenle öncelikle yazılımdan ne istendiğinin doğru bir biçimde tanımlanması gerekir.
Yazılım geliştirmede kodlamaya başlamadan önceki aşamada ilk olarak genel bir kapsam çıkartılması gerekir. Bu kapsamla birlikte yazılımın üzerinde çalışacağı donanım bileşenlerini de kapsayacak şekilde bir sistem analizi yapılır. Ardından yazılım ve donanım gereksinimleri ana hatlarıyla belirlenince yazılım için proje planı yapılır, gerekiyorsa ekip oluşturulur ve sonrasında yazılım isterleri çözümlenmeye başlar.
İlk olarak yukarıdaki paragrafın anlamını biraz daha açık hale getirelim. Bu yazı boyunca kavramların ve işleyişin daha iyi anlaşılması açısından bir örnek üzerinden gideceğim. Bir diyetisyen için randevu sistemi. Her bir kavramı ve adımı bu örnekler için uygulanışını da okuduğunuzda daha iyi anlayacağınızı umuyorum.
Kapsam dediğimiz şey, projenin neleri içerip neleri içermeyeceğinin belirlenmesidir. Müşteriler, bu öğretmenleriniz, eşiniz, dostunuz da olabilir, her zaman birçok şey söyleyeceklerdir. Müşterinin sizden isteyeceği her şey yazılım içinde olmalı mıdır? Eğer sonsuz zamanız, bütçeniz, enerjiniz ve sabrınız varsa olabilir. Ama her projenin bir başlangıç ve bir bitiş zamanı vardır. Yani zamanınız sınırlıdır. Bu arada kaynaklarınız da sınırlı. Tek başınıza belirlenen süre içinde yazabileceğiniz kod miktarı da sınırlıdır. E işi yaparken bu kadar sınır varsa, işi çerçevelerken de bazı sınırlar koymalıyız. Biz buna kapsam yönetimi diyoruz.
Randevu sistemini ele alalım. Müşteri bir diyetisyen, bir de sekreteri var. Randevuları ve hastaları takip ediyor. İlk olarak diyetisyenle görüşmeye başlamalıyız. Diyetisyenden geliştireceğimiz sistemden neler beklediğini ana hatlarıyla öğrenmeliyiz. Diyetisyen bu durumda aklına gelen gelmeyen birçok şey söylemeye başlayacaktır.
DİYETİSYEN: Hastalarım internet üzerinden randevu alabilmeli. Sekreterim ve ben de bu randevuları dilediğimiz zaman izleyebilmeliyiz. Bir hasta randevusunu erteleyebilir veya iptal edebilir. Ama bunu en geç 2 iş günü öncesinde yapmalı. Ayrıca gerektiğinde ben de randevuları iptal edebilirim. Bu durumun da hastalara sms ve email ile bildirilmesi gerekir. Her zaman aynı saatlerde çalışmayabilirim. Bazen bazı günler çalışmayabilirim. Bu nedenle takvimin esnek bir şekilde yönetilebiliyor olması gerekiyor. İki hafta sonra yeni yerimize taşınıyoruz. Orada bu sistemin çalışıyor olması benim için önemli. He bir de ek olarak tabii ki hastanın iletişim, kişisel bilgileri, tahlil vb. ve verdiğim diyetleri de sistemin takip ediyor olması lazım.
Şimdi gördünüz mü diyetisyenden gelen son faullü hareketi! Son anda “he bir de” diyerek eklediği şeyler randevu sisteminin kendisinden birkaç kat büyük bir iş. Burada yapmanız gereken diyetisyeni biraz aydınlatmaktır. Randevu sisteminin kapsamını belirleyerek ona yardımcı olalım.
SİZ: Hastanın kişisel, iletişim, tahlil ve diyet gibi bilgilerini tutacak hasta takip sistemi tamamen ayrı bir iştir. Dilerseniz onu da randevu takip sisteminin ardından planlayabiliriz. Ancak anlattıklarınızdan iki ayrı sisteme ihtiyacınız olduğu anlaşılıyor: Randevu takip sistemi ve hasta takip sistemi. Bu iki sistemin birden iki hafta içinde yetişmesi mümkün değil. Bu nedenle biriyle başlamamızı öneririm.
Kapsamı belirlemeye başladık. İlk yaptığımız en üst seviyede sistemleri isimlendirerek kapsamın adını vermek oldu. Şimdi diyetisyeni makul bir insan olarak düşünüp söylediklerinizi değerlendirdiğini ve randevu takip sistemini öncelikli olarak ilk yapmanızı istediğini varsayıyoruz. Şimdi sıra yazılım isterlerini belirlemeye geldi. Yazılım isteri dediğimiz şey, o yazılım yerine getireceği işlevlerin belirlenmesidir. Ek olarak temel iş kuralları, performans beklentileri, kısıtlar vb. şeyler de bu aşamada açıklığa kavuşturulur. Teyitler ve sorularla, olabildiğince temkinli olarak yazılım isterlerini çözümlemeye başlayalım.
Öncelikle elimizdeki bilgileri bir gözden geçirelim:
- Herkes, her yerden sistemi kullanabilecek. Bu projemizin web tabanlı olmasını gerektirecek. Hemen diyetisyene soruyoruz.
SİZ: Herkesin dilediği zaman erişebileceği bir sistem için web tabanlı bir proje geliştirmemiz gerekiyor. Bu yazılıma ek olarak bir web sunucusu ve alan adı kiralanmasını gerektirir. (Sistem çözümlemesi) Web sunucunuz ve alan adınız var mı? Yoksa bunlarla da benim mi ilgilenmemi istersiniz?
DİYETİSYEN: Alan adım ve web sunucum var. Bu konularla ilgilenen arkadaşın ismini ve iletişim bilgilerini size vereceğim. Projenin web ortamında çalışması için gerekli desteği ondan alabileceksiniz.
Evet, şimdi projemizin bir web projesi olacağını netleştirdik. Şimdi sıra işleyişe geçti.
- Her zaman aynı saatlerde çalışmayabilirim. Bazen bazı günler çalışmayabilirim. Bu nedenle takvimin esnek bir şekilde yönetilebiliyor olması gerekiyor.
SİZ: Öncelikle sistemde bir randevu takvimi oluşturarak başlamak gerecek. Bu takvimde siz ya da sekreteriniz önümüzdeki herhangi bir gün için çalışma saatlerinizi direkt olarak ilgili günü seçerek saat aralığını verip randevuları tanımlayabilmelisiniz? Doğru anlamış mıyım?
DİYETİSYEN: Evet ama her gün için teker teker randevu tanımlamayla uğraşmamalıyız. Yani genel olarak seanslar 45 dakika sürer. Sabah saat 10.00 ile akşam saat 17.00 arası normal çalışma saatlerimizdir. Öğlen 13.00 ile 14.00 arasında da yemek arası veririm. Cumartesi ve Pazar günleri normalde çalışmam. Bu standart olarak tanımlı olmalı. Ama biz gerektiğinde ek seanslar ya da günler ekleyebilmeliyiz.
Otomatik tekrarlayan randevu biraz sizi yoracak gibi görünüyor. Hemen itiraz mı etmeli, yoksa bu istek makul mü?
Burada çok kolay bir formül var. Bu istek,
- Mutlaka olmalı mı?
- Olursa iyi olur mu?
- Olmasa da olur mu?
Diyetisyenin randevu işlemlerini bir yazılım üzerinden takip etme nedenlerinden biri de işlerin kolaylaşmasını sağlamak ve sekreterinin yoğunluğuna azaltmak. Her gün için tekrar tekrar takvim girdisi oluşturulmasını beklemek bu iş için pek de doğru değil. Yani bu ister, bu proje için mutlaka olmalı. Bunu kenara koyduk.
SİZ: Sistemde siz randevuları tanımladıktan sonra müşterileriniz randevu alabilecek, erteleyebilecek ya da iptal edebilecek. Sistem erteleme ve iptal için 2 iş günü öncesine kadar müsaade edecek, sonrasında kullanıcı bu işlemleri yapamayacak. Peki, bu 2 iş gününün daha sonra 1 iş günü olması ya da 3 günce çıkması ya da belirli bir müşteriye özel olarak değiştirilmesi söz konusu olabilir mi?
İş kuralını sorguluyoruz. Parametrik mi yapalım? Sabit mi? İstisnaları var mı?
DİYETİSYEN: Çok emin değilim ama bu 2 gün değişmez gibi. Belki 3 gün olabilir ama 1 güne inmez. Özel müşterilerimiz için de şöyle bir şey olabilir: İnternet üzerinden yine işlem yapamazlar ama bizi telefonla aradıklarında sekreterim o randevuyu boşa çıkarabilir. Böylece o seansı boş geçirmek zorunda kalmayız.
Evet, randevu iptal ve ertelemeyi de çözümledik. İptal ve erteleme için maksimum gün sayısı parametrik olmalı. Hastalar bu parametrik değere bağlı olarak erteleme/iptal işi yapabilir/yapamaz olmalılar. Ancak doktor ya da sekreter diledikleri zaman randevu erteleme ya da iptali yapabilmeliler.
- Ayrıca gerektiğinde ben de randevuları iptal edebilirim. Bu durumun da hastalara SMS ve e-mail ile bildirilmesi gerekir.
Hastalar için randevularını iptal etmenin dışında bir de diyetisyen için belirli bir aralıktaki randevuları iptal etme söz konusu. Peki, bu durumda sistem nasıl çalışmalı? Yani diyelim ki sizin bugün saat 15.00 diyetisyenle randevunuz vardı. Diyetisyenin çok önemli bir işi çıktı ve bugünkü bütün randevuları iptal etti. Yarın, öbür gün, hatta bütün bir hafta için tüm seanslar dolu. Size bu alacaklı olduğunuz seans için nasıl bir çözüm önerilecek. Normalde bu iş nasıl çözümleniyordu?
SİZ: Peki randevularını iptal ettiğiniz hastalara nasıl bir çözüm getiriyorsunuz?
DİYETİSYEN: Her biri teker teker aranıyor ve hasta kabul ederse mevcut seanslardan uygun olan birine davet ediliyorlar. Eğer hasta kabul etmezse, normal seansların dışına ek seans konularak hastaya randevu veriliyor.
Bu cevabı ek seans tanımlama işlevimiz yerine getirecek zaten. Şimdi gelelim SMS ve Email ile randevu iptalini bildirmeye. Bu durumda her bir hasta, randevu sistemi üzerinden kayıt olurken cep telefonu ve email bilgilerini girmek zorunda.
SİZ: Hastalarınız kayıt olduklarında gerektiğinde email ve sms gönderebilmek için email adreslerini ve cep telefonlarını almamız gerekecek. Ayrıca tabii ki isimlerini de. Bunların haricinde hastayla ilgili randevu sisteminde olmasını istediğiniz bilgiler var mı?
DİYETİSYEN: Hastanın adı, soyadı, emaili, cep telefon numarası ve oturduğu semt bilgileri bizim için yeterli. SMS için benim çalıştığım bir kurum var. O kurumdan gerekli desteği alabilirsiniz.
Buraya kadar yazılımın hem kapsamını belirlemiş olduk hem de isterlerin büyük kısmını ana hatlarıyla şekillendirdik. Şimdi elimizdeki bilgilerle isterleri bir toparlayalım ve yazılımımızın işlevlerini sıralayalım.
1. Sistem otomatik olarak takvim oluşturacak. Pazartesi – Cuma günleri aralığında her gün için sabah saat 10.00 akşam 17.00 aralığında 45’er dakikalık seanslar tanımlayacak. Bu seanslara öğlen 13.00 – 14.00 arası dâhil değil. (Burada hemen aklımıza bir soru gelmesi lazım. Seanslar aralıksız olarak mı atanmalı, yoksa iki seans arasına boşluk konmalı mı?)
2. Sekreter ya da diyetisyen istediklerinde belirli seansları kapatabilmeli ya da yeni seans açabilmeliler.
3. Hastalar ad, soyad, semt, cep telefon, email bilgilerini girerek seçecekleri bir gün ve seansa randevu alabilirler.
4. Hastalar belirli bir süre önceden (2 iş günü) randevularını iptal edebilirler ya da erteleyebilirler. Her iki durum da ilgili seansı boşa çıkartır ve başka birinin randevu alabilmesini sağlar. Erteleme için hastanın bilgilerini girmeye gerek kalmaksızın takvimden yeni bir boş seans seçmesi yeterli olur.
5. Bir ya da birçok seans için sekreterin ya da diyetisyenin seans iptali. Bu durumda ilgili seanslara randevu almış hastalara sms ve email mesajları gider.
İşlevsel isterlerimizi ana hatlarıyla belirledik. Şimdi bir kez daha diyetisyenimizle görüşme yapalım. Sonrasında sekreterimize de birkaç sorumuz olur. Ardından yazılımımızın tasarımına geçebiliriz.
Diyetisyenimize randevular arasında boşluk olup olmayacağını sorduk. Sekreterle konuşarak şimdiye kadar bu işlerin nasıl yapıldığını dinledik. Analizimizde eksik var mı doğrulamasını yaptık. Hatta birkaç da hastayla görüştük. Mevcut durumda şikayetçi oldukları şeyleri öğrendik, ardından bu işi internet üzerinden yapıyor olsalar sistemden neler beklerlerdi öğrendik. Sonrasında da işlevsel analizimizi güncelleyip, ne tür kullanıcı ekranları olacağı ve ne tip raporlar alınabileceğini de belirten bir belge hazırlayarak diyetisyenle analiz aşamasındaki son görüşmemizi yapıyoruz.
DİYETİSYEN VE SEKRETER İŞLEVLERİ:
1. Sistem yöneticisi girişi: Diyetisyen ya da sekreterin kullanıcı adı ve parolasıyla girerek, onlara özel işlemleri gerçekleştirmesini sağlayacak giriş ekranı.
2. Sistem yöneticisi parola değiştirme: Sisteme bir diyetisyen ve bir sekreter olmak üzere iki kullanıcı tanımlanacaktır. Bu kullanıcılar diledikleri zaman parolalarını değiştirebilirler.
3. Sisteme çalışma günlerinin tanıtılması: Diyetisyen ya da sekreter sistem yöneticisi ekranından kendilerine gösterilen günleri (Pazartesi, Salı, Çarşamba, Perşembe, Cuma, cumartesi, Pazar) işaretleyerek çalışma günlerini belirlerler.
4. Sisteme çalışma saatlerinin tanıtılması: Diyetisyen ya da sekreter sistem yöneticisi ekranından seçtikleri bir çalışma günü için sabah ve öğlen çalışma saat aralığını girerler. (Öğlen yemeği saatleri dışarıda kalacak şekilde.)
5. Ek seans oluşturma: Diyetisyen ya da sekreter sistem yöneticisi ekranından seçtikleri bir tarih için, o günde olmayan ek bir seansı başlangıç saatini vererek tanımlarlar.
6. Seans iptali: Diyetisyen ya da sekreter sistem yöneticisi ekranından seçtikleri bir gün için belirli seansları, bir günün tamamını, ya birden fazla günü iptal edebilirler. Bu durumda sistem iptal edilmiş seanslara kayıtlı hastalara email ve sms gönderir.
7. Seans izleme/sorgulama: Sekreter ya da doktor belirli bir tarihteki seansların randevu durumunu izleyebilirler.
8. Sistemin otomatik olarak seans oluşturması: Kullanıcı ya da sistem yöneticileri belirli bir gün için seansları listelemek istediklerinde, eğer o gün için daha önceden seanslar oluşturulmamış ise, öncelikle ilgili günün çalışma günü olup olmadğına bakılır. İlgili gün çalışma günüyse, haftanın o günü için belirlenmiş çalışma saatlerine bakılırak, 45 dakika seans 15 dakika iki seans arası olacak şekilde seanslar tanımlanır. (Sistem bu işlevi arka planda otomatik olarak yapacaktır.)
HASTA İŞLEVLERİ:
1. Randevu alma: Hasta seçtiği bir gün için kendisine listelenen boş seanslardan dilediği birine ad, soyad, semt, cep telefonu ve email bilgilerini girerek kayıt olur.
2. Randevu iptali: Hasta randevu takibi için cep telefonu numarasını girerek almış olduğu randevuyu görüntüler. Eğer süresi içindeyse randevu iptal seçeneğini görebilecektir. Bu seçeneği tıklayarak iptal nedenini girer ve randevu iptal işlemi gerçekleşir.
3. Randevu erteleme: Hasta randevu takibi için cep telefonu numarasını girerek almış olduğu randevuyu görüntüler. Eğer süresi içindeyse randevu ertele seçeneğini görebilecektir. Bu seçeneği tıklayarak erteleme nedenini girer ve yeni randevu seansını seçerek erteleme işlemini gerçekleştirir.
SİSTEM YÖNETİM EKRANLARI:
1. Diyetisyen/sekreter sistem yönetim paneli giriş ekranı.
2. Diyetisyen/sekreter parola güncelleme ekranı.
3. Sistem yönetim menüsü.
4. Çalışma günleri tanıtma ekranı.
5. Çalışma saatleri tanıtma ekranı.
6. Ek seans giriş ekranı.
7. Seans kapatma ekranı.
8. Seans iptal ekranı.
9. Seans izleme/sorgulama ekranı.
HASTA EKRANLARI:
1. Randevu sorgulama ekranı.
2. Randevu alma ekranı.
3. Randevu iptal ekranı.
4. Randevu erteleme ekranı.
Yukarıdaki listelerle diyetisyene gidip, çözümlemeniz için teyit almanız analiz aşamasındaki son adım. Bundan sonraki aşamada tasarıma geçeceğiz. Sizin de fark ettiğiniz gibi bu basit örnek bile analizin ne kadar ciddi bir iş olduğunu açıkça göstermektedir.
Aslında ben bu örnekte diyetisyeni pek konuşturmadım. Daha neler neler çıkardı o diyetisyenden…
SON SÖZ : ANALİZ,ANALİZ,ANALİZ.......... (benden)
Yazılım geliştirme sadece kodlamaktan ibaret değildir. Bir problemin çözümü olarak nitelediğimiz yazılımların ne yapacağını ve nasıl yapacağını belirlediğimiz yani problemi tanımladığımız aşama “Analiz” aşamasıdır. Yazdığınız kod ancak isteneni doğru bir biçimde yerine getiriyorsa başarılı bir yazılımdır. Bu nedenle öncelikle yazılımdan ne istendiğinin doğru bir biçimde tanımlanması gerekir.
Yazılım geliştirmede kodlamaya başlamadan önceki aşamada ilk olarak genel bir kapsam çıkartılması gerekir. Bu kapsamla birlikte yazılımın üzerinde çalışacağı donanım bileşenlerini de kapsayacak şekilde bir sistem analizi yapılır. Ardından yazılım ve donanım gereksinimleri ana hatlarıyla belirlenince yazılım için proje planı yapılır, gerekiyorsa ekip oluşturulur ve sonrasında yazılım isterleri çözümlenmeye başlar.
İlk olarak yukarıdaki paragrafın anlamını biraz daha açık hale getirelim. Bu yazı boyunca kavramların ve işleyişin daha iyi anlaşılması açısından bir örnek üzerinden gideceğim. Bir diyetisyen için randevu sistemi. Her bir kavramı ve adımı bu örnekler için uygulanışını da okuduğunuzda daha iyi anlayacağınızı umuyorum.
Kapsam dediğimiz şey, projenin neleri içerip neleri içermeyeceğinin belirlenmesidir. Müşteriler, bu öğretmenleriniz, eşiniz, dostunuz da olabilir, her zaman birçok şey söyleyeceklerdir. Müşterinin sizden isteyeceği her şey yazılım içinde olmalı mıdır? Eğer sonsuz zamanız, bütçeniz, enerjiniz ve sabrınız varsa olabilir. Ama her projenin bir başlangıç ve bir bitiş zamanı vardır. Yani zamanınız sınırlıdır. Bu arada kaynaklarınız da sınırlı. Tek başınıza belirlenen süre içinde yazabileceğiniz kod miktarı da sınırlıdır. E işi yaparken bu kadar sınır varsa, işi çerçevelerken de bazı sınırlar koymalıyız. Biz buna kapsam yönetimi diyoruz.
Randevu sistemini ele alalım. Müşteri bir diyetisyen, bir de sekreteri var. Randevuları ve hastaları takip ediyor. İlk olarak diyetisyenle görüşmeye başlamalıyız. Diyetisyenden geliştireceğimiz sistemden neler beklediğini ana hatlarıyla öğrenmeliyiz. Diyetisyen bu durumda aklına gelen gelmeyen birçok şey söylemeye başlayacaktır.
DİYETİSYEN: Hastalarım internet üzerinden randevu alabilmeli. Sekreterim ve ben de bu randevuları dilediğimiz zaman izleyebilmeliyiz. Bir hasta randevusunu erteleyebilir veya iptal edebilir. Ama bunu en geç 2 iş günü öncesinde yapmalı. Ayrıca gerektiğinde ben de randevuları iptal edebilirim. Bu durumun da hastalara sms ve email ile bildirilmesi gerekir. Her zaman aynı saatlerde çalışmayabilirim. Bazen bazı günler çalışmayabilirim. Bu nedenle takvimin esnek bir şekilde yönetilebiliyor olması gerekiyor. İki hafta sonra yeni yerimize taşınıyoruz. Orada bu sistemin çalışıyor olması benim için önemli. He bir de ek olarak tabii ki hastanın iletişim, kişisel bilgileri, tahlil vb. ve verdiğim diyetleri de sistemin takip ediyor olması lazım.
Şimdi gördünüz mü diyetisyenden gelen son faullü hareketi! Son anda “he bir de” diyerek eklediği şeyler randevu sisteminin kendisinden birkaç kat büyük bir iş. Burada yapmanız gereken diyetisyeni biraz aydınlatmaktır. Randevu sisteminin kapsamını belirleyerek ona yardımcı olalım.
SİZ: Hastanın kişisel, iletişim, tahlil ve diyet gibi bilgilerini tutacak hasta takip sistemi tamamen ayrı bir iştir. Dilerseniz onu da randevu takip sisteminin ardından planlayabiliriz. Ancak anlattıklarınızdan iki ayrı sisteme ihtiyacınız olduğu anlaşılıyor: Randevu takip sistemi ve hasta takip sistemi. Bu iki sistemin birden iki hafta içinde yetişmesi mümkün değil. Bu nedenle biriyle başlamamızı öneririm.
Kapsamı belirlemeye başladık. İlk yaptığımız en üst seviyede sistemleri isimlendirerek kapsamın adını vermek oldu. Şimdi diyetisyeni makul bir insan olarak düşünüp söylediklerinizi değerlendirdiğini ve randevu takip sistemini öncelikli olarak ilk yapmanızı istediğini varsayıyoruz. Şimdi sıra yazılım isterlerini belirlemeye geldi. Yazılım isteri dediğimiz şey, o yazılım yerine getireceği işlevlerin belirlenmesidir. Ek olarak temel iş kuralları, performans beklentileri, kısıtlar vb. şeyler de bu aşamada açıklığa kavuşturulur. Teyitler ve sorularla, olabildiğince temkinli olarak yazılım isterlerini çözümlemeye başlayalım.
Öncelikle elimizdeki bilgileri bir gözden geçirelim:
- Herkes, her yerden sistemi kullanabilecek. Bu projemizin web tabanlı olmasını gerektirecek. Hemen diyetisyene soruyoruz.
SİZ: Herkesin dilediği zaman erişebileceği bir sistem için web tabanlı bir proje geliştirmemiz gerekiyor. Bu yazılıma ek olarak bir web sunucusu ve alan adı kiralanmasını gerektirir. (Sistem çözümlemesi) Web sunucunuz ve alan adınız var mı? Yoksa bunlarla da benim mi ilgilenmemi istersiniz?
DİYETİSYEN: Alan adım ve web sunucum var. Bu konularla ilgilenen arkadaşın ismini ve iletişim bilgilerini size vereceğim. Projenin web ortamında çalışması için gerekli desteği ondan alabileceksiniz.
Evet, şimdi projemizin bir web projesi olacağını netleştirdik. Şimdi sıra işleyişe geçti.
- Her zaman aynı saatlerde çalışmayabilirim. Bazen bazı günler çalışmayabilirim. Bu nedenle takvimin esnek bir şekilde yönetilebiliyor olması gerekiyor.
SİZ: Öncelikle sistemde bir randevu takvimi oluşturarak başlamak gerecek. Bu takvimde siz ya da sekreteriniz önümüzdeki herhangi bir gün için çalışma saatlerinizi direkt olarak ilgili günü seçerek saat aralığını verip randevuları tanımlayabilmelisiniz? Doğru anlamış mıyım?
DİYETİSYEN: Evet ama her gün için teker teker randevu tanımlamayla uğraşmamalıyız. Yani genel olarak seanslar 45 dakika sürer. Sabah saat 10.00 ile akşam saat 17.00 arası normal çalışma saatlerimizdir. Öğlen 13.00 ile 14.00 arasında da yemek arası veririm. Cumartesi ve Pazar günleri normalde çalışmam. Bu standart olarak tanımlı olmalı. Ama biz gerektiğinde ek seanslar ya da günler ekleyebilmeliyiz.
Otomatik tekrarlayan randevu biraz sizi yoracak gibi görünüyor. Hemen itiraz mı etmeli, yoksa bu istek makul mü?
Burada çok kolay bir formül var. Bu istek,
- Mutlaka olmalı mı?
- Olursa iyi olur mu?
- Olmasa da olur mu?
Diyetisyenin randevu işlemlerini bir yazılım üzerinden takip etme nedenlerinden biri de işlerin kolaylaşmasını sağlamak ve sekreterinin yoğunluğuna azaltmak. Her gün için tekrar tekrar takvim girdisi oluşturulmasını beklemek bu iş için pek de doğru değil. Yani bu ister, bu proje için mutlaka olmalı. Bunu kenara koyduk.
SİZ: Sistemde siz randevuları tanımladıktan sonra müşterileriniz randevu alabilecek, erteleyebilecek ya da iptal edebilecek. Sistem erteleme ve iptal için 2 iş günü öncesine kadar müsaade edecek, sonrasında kullanıcı bu işlemleri yapamayacak. Peki, bu 2 iş gününün daha sonra 1 iş günü olması ya da 3 günce çıkması ya da belirli bir müşteriye özel olarak değiştirilmesi söz konusu olabilir mi?
İş kuralını sorguluyoruz. Parametrik mi yapalım? Sabit mi? İstisnaları var mı?
DİYETİSYEN: Çok emin değilim ama bu 2 gün değişmez gibi. Belki 3 gün olabilir ama 1 güne inmez. Özel müşterilerimiz için de şöyle bir şey olabilir: İnternet üzerinden yine işlem yapamazlar ama bizi telefonla aradıklarında sekreterim o randevuyu boşa çıkarabilir. Böylece o seansı boş geçirmek zorunda kalmayız.
Evet, randevu iptal ve ertelemeyi de çözümledik. İptal ve erteleme için maksimum gün sayısı parametrik olmalı. Hastalar bu parametrik değere bağlı olarak erteleme/iptal işi yapabilir/yapamaz olmalılar. Ancak doktor ya da sekreter diledikleri zaman randevu erteleme ya da iptali yapabilmeliler.
- Ayrıca gerektiğinde ben de randevuları iptal edebilirim. Bu durumun da hastalara SMS ve e-mail ile bildirilmesi gerekir.
Hastalar için randevularını iptal etmenin dışında bir de diyetisyen için belirli bir aralıktaki randevuları iptal etme söz konusu. Peki, bu durumda sistem nasıl çalışmalı? Yani diyelim ki sizin bugün saat 15.00 diyetisyenle randevunuz vardı. Diyetisyenin çok önemli bir işi çıktı ve bugünkü bütün randevuları iptal etti. Yarın, öbür gün, hatta bütün bir hafta için tüm seanslar dolu. Size bu alacaklı olduğunuz seans için nasıl bir çözüm önerilecek. Normalde bu iş nasıl çözümleniyordu?
SİZ: Peki randevularını iptal ettiğiniz hastalara nasıl bir çözüm getiriyorsunuz?
DİYETİSYEN: Her biri teker teker aranıyor ve hasta kabul ederse mevcut seanslardan uygun olan birine davet ediliyorlar. Eğer hasta kabul etmezse, normal seansların dışına ek seans konularak hastaya randevu veriliyor.
Bu cevabı ek seans tanımlama işlevimiz yerine getirecek zaten. Şimdi gelelim SMS ve Email ile randevu iptalini bildirmeye. Bu durumda her bir hasta, randevu sistemi üzerinden kayıt olurken cep telefonu ve email bilgilerini girmek zorunda.
SİZ: Hastalarınız kayıt olduklarında gerektiğinde email ve sms gönderebilmek için email adreslerini ve cep telefonlarını almamız gerekecek. Ayrıca tabii ki isimlerini de. Bunların haricinde hastayla ilgili randevu sisteminde olmasını istediğiniz bilgiler var mı?
DİYETİSYEN: Hastanın adı, soyadı, emaili, cep telefon numarası ve oturduğu semt bilgileri bizim için yeterli. SMS için benim çalıştığım bir kurum var. O kurumdan gerekli desteği alabilirsiniz.
Buraya kadar yazılımın hem kapsamını belirlemiş olduk hem de isterlerin büyük kısmını ana hatlarıyla şekillendirdik. Şimdi elimizdeki bilgilerle isterleri bir toparlayalım ve yazılımımızın işlevlerini sıralayalım.
1. Sistem otomatik olarak takvim oluşturacak. Pazartesi – Cuma günleri aralığında her gün için sabah saat 10.00 akşam 17.00 aralığında 45’er dakikalık seanslar tanımlayacak. Bu seanslara öğlen 13.00 – 14.00 arası dâhil değil. (Burada hemen aklımıza bir soru gelmesi lazım. Seanslar aralıksız olarak mı atanmalı, yoksa iki seans arasına boşluk konmalı mı?)
2. Sekreter ya da diyetisyen istediklerinde belirli seansları kapatabilmeli ya da yeni seans açabilmeliler.
3. Hastalar ad, soyad, semt, cep telefon, email bilgilerini girerek seçecekleri bir gün ve seansa randevu alabilirler.
4. Hastalar belirli bir süre önceden (2 iş günü) randevularını iptal edebilirler ya da erteleyebilirler. Her iki durum da ilgili seansı boşa çıkartır ve başka birinin randevu alabilmesini sağlar. Erteleme için hastanın bilgilerini girmeye gerek kalmaksızın takvimden yeni bir boş seans seçmesi yeterli olur.
5. Bir ya da birçok seans için sekreterin ya da diyetisyenin seans iptali. Bu durumda ilgili seanslara randevu almış hastalara sms ve email mesajları gider.
İşlevsel isterlerimizi ana hatlarıyla belirledik. Şimdi bir kez daha diyetisyenimizle görüşme yapalım. Sonrasında sekreterimize de birkaç sorumuz olur. Ardından yazılımımızın tasarımına geçebiliriz.
Diyetisyenimize randevular arasında boşluk olup olmayacağını sorduk. Sekreterle konuşarak şimdiye kadar bu işlerin nasıl yapıldığını dinledik. Analizimizde eksik var mı doğrulamasını yaptık. Hatta birkaç da hastayla görüştük. Mevcut durumda şikayetçi oldukları şeyleri öğrendik, ardından bu işi internet üzerinden yapıyor olsalar sistemden neler beklerlerdi öğrendik. Sonrasında da işlevsel analizimizi güncelleyip, ne tür kullanıcı ekranları olacağı ve ne tip raporlar alınabileceğini de belirten bir belge hazırlayarak diyetisyenle analiz aşamasındaki son görüşmemizi yapıyoruz.
DİYETİSYEN VE SEKRETER İŞLEVLERİ:
1. Sistem yöneticisi girişi: Diyetisyen ya da sekreterin kullanıcı adı ve parolasıyla girerek, onlara özel işlemleri gerçekleştirmesini sağlayacak giriş ekranı.
2. Sistem yöneticisi parola değiştirme: Sisteme bir diyetisyen ve bir sekreter olmak üzere iki kullanıcı tanımlanacaktır. Bu kullanıcılar diledikleri zaman parolalarını değiştirebilirler.
3. Sisteme çalışma günlerinin tanıtılması: Diyetisyen ya da sekreter sistem yöneticisi ekranından kendilerine gösterilen günleri (Pazartesi, Salı, Çarşamba, Perşembe, Cuma, cumartesi, Pazar) işaretleyerek çalışma günlerini belirlerler.
4. Sisteme çalışma saatlerinin tanıtılması: Diyetisyen ya da sekreter sistem yöneticisi ekranından seçtikleri bir çalışma günü için sabah ve öğlen çalışma saat aralığını girerler. (Öğlen yemeği saatleri dışarıda kalacak şekilde.)
5. Ek seans oluşturma: Diyetisyen ya da sekreter sistem yöneticisi ekranından seçtikleri bir tarih için, o günde olmayan ek bir seansı başlangıç saatini vererek tanımlarlar.
6. Seans iptali: Diyetisyen ya da sekreter sistem yöneticisi ekranından seçtikleri bir gün için belirli seansları, bir günün tamamını, ya birden fazla günü iptal edebilirler. Bu durumda sistem iptal edilmiş seanslara kayıtlı hastalara email ve sms gönderir.
7. Seans izleme/sorgulama: Sekreter ya da doktor belirli bir tarihteki seansların randevu durumunu izleyebilirler.
8. Sistemin otomatik olarak seans oluşturması: Kullanıcı ya da sistem yöneticileri belirli bir gün için seansları listelemek istediklerinde, eğer o gün için daha önceden seanslar oluşturulmamış ise, öncelikle ilgili günün çalışma günü olup olmadğına bakılır. İlgili gün çalışma günüyse, haftanın o günü için belirlenmiş çalışma saatlerine bakılırak, 45 dakika seans 15 dakika iki seans arası olacak şekilde seanslar tanımlanır. (Sistem bu işlevi arka planda otomatik olarak yapacaktır.)
HASTA İŞLEVLERİ:
1. Randevu alma: Hasta seçtiği bir gün için kendisine listelenen boş seanslardan dilediği birine ad, soyad, semt, cep telefonu ve email bilgilerini girerek kayıt olur.
2. Randevu iptali: Hasta randevu takibi için cep telefonu numarasını girerek almış olduğu randevuyu görüntüler. Eğer süresi içindeyse randevu iptal seçeneğini görebilecektir. Bu seçeneği tıklayarak iptal nedenini girer ve randevu iptal işlemi gerçekleşir.
3. Randevu erteleme: Hasta randevu takibi için cep telefonu numarasını girerek almış olduğu randevuyu görüntüler. Eğer süresi içindeyse randevu ertele seçeneğini görebilecektir. Bu seçeneği tıklayarak erteleme nedenini girer ve yeni randevu seansını seçerek erteleme işlemini gerçekleştirir.
SİSTEM YÖNETİM EKRANLARI:
1. Diyetisyen/sekreter sistem yönetim paneli giriş ekranı.
2. Diyetisyen/sekreter parola güncelleme ekranı.
3. Sistem yönetim menüsü.
4. Çalışma günleri tanıtma ekranı.
5. Çalışma saatleri tanıtma ekranı.
6. Ek seans giriş ekranı.
7. Seans kapatma ekranı.
8. Seans iptal ekranı.
9. Seans izleme/sorgulama ekranı.
HASTA EKRANLARI:
1. Randevu sorgulama ekranı.
2. Randevu alma ekranı.
3. Randevu iptal ekranı.
4. Randevu erteleme ekranı.
Yukarıdaki listelerle diyetisyene gidip, çözümlemeniz için teyit almanız analiz aşamasındaki son adım. Bundan sonraki aşamada tasarıma geçeceğiz. Sizin de fark ettiğiniz gibi bu basit örnek bile analizin ne kadar ciddi bir iş olduğunu açıkça göstermektedir.
Aslında ben bu örnekte diyetisyeni pek konuşturmadım. Daha neler neler çıkardı o diyetisyenden…
SON SÖZ : ANALİZ,ANALİZ,ANALİZ.......... (benden)
2.05.2008
XML-DTD-XSD arası dönüşüm (convert)
DTD to XML Schema ,XML Document to XML Schema,XML Document to DTD
In an effort to help our Allora customers to deal with conversions between XMLSchemas and DTDS, as well generating XML Schemas and DTDs from XML documents, we developed some XML Utilities that you can use free of charge from this web page.
kaynak: http://www.hitsw.com/xml_utilites/
In an effort to help our Allora customers to deal with conversions between XMLSchemas and DTDS, as well generating XML Schemas and DTDs from XML documents, we developed some XML Utilities that you can use free of charge from this web page.
kaynak: http://www.hitsw.com/xml_utilites/
Kaydol:
Kayıtlar (Atom)