marscommentary.blogspot.com

火星紀事

最近拜讀邱郁惠老師的大作「學會UML/OOAD，這樣開始就對了」，不禁想起從UseCase到領域模型曾是我的一大瓶頸。也許會有人覺得奇怪，這中間不就是名詞轉化為類別，動詞轉化為函式…。我只能說絕不僅是如此，這裏就借用邱老師書上第一個使用者案例，概說一下我的想法。驗證失敗：累積5次登入失敗，即鎖定，並出現請會員主動聯絡系統管理員的訊息. BR3：會員累積5次登入失敗，即鎖定該會員帳號。只要登入成功，即失敗次數歸零. 取自四色原型的觀念，模型必須區分靜態與動態。像PPT這種靜態的物件其屬性應該很少需要修改，所以登入的資訊不適合與會員放於一塊，所以拉出一個較為動態的物件MemberLogin，較為適當。取自DDD的觀念，規則最好可以獨立成Spec物件，這樣設計時自然會變成可動態抽換，而且說不定日後鎖定的規則不是5次，或再加上間隔時間的限制也說不定。 MemberLoginStatus，也許最後設計時只是個字串、長整數、enum之類，但為了分析上的清晰，我還是傾向將它獨立成類別。先來看一半的ER Model。UsersGroups就是Role，伴隨著自身關聯構成Role Hie...再來看另一半的ERMo...

http://marscommentary.blogspot.com/

OVERVIEW OF marscommentary.blogspot.com

TRAFFIC RANK

>1,000,000

REVIEWS

0

PAGES IN THIS WEBSITE

19

LINKS TO THIS WEBSITE

CONTACTS

ADDRESSES

SOCIAL LINKS

ONLINE SINCE

WEBSITE DETAILS

SEO

PAGES

SIMILAR SITES

TRAFFIC RANK FOR MARSCOMMENTARY.BLOGSPOT.COM

TODAY'S RATING

>1,000,000

TRAFFIC RANK - AVERAGE PER MONTH

BEST MONTH

June

AVERAGE PER DAY Of THE WEEK

HIGHEST TRAFFIC ON

Friday

TRAFFIC BY CITY

Sign up

CUSTOMER REVIEWS

Average Rating: 3.3 out of 5 with 9 reviews

5 star

1

4 star

3

3 star

4

2 star

0

1 star

1

Hey there! Start your review of marscommentary.blogspot.com

AVERAGE USER RATING

Write a Review

WEBSITE PREVIEW

LOAD TIME

FAVICON PREVIEW

16x16
32x32
64x64
128x128

CONTACTS AT MARSCOMMENTARY.BLOGSPOT.COM

ADD CONTACT

Login

TO VIEW CONTACTS

Remove Contacts

FOR PRIVACY ISSUES

CONTENT

PAGES IN
THIS WEBSITE

19

SSL

EXTERNAL LINKS

0

SITE IP

172.217.3.97

LOAD TIME

0 sec

SCORE

6.2

PAGE TITLE

火星紀事 | marscommentary.blogspot.com Reviews

<META> DESCRIPTION

最近拜讀邱郁惠老師的大作「學會UML/OOAD，這樣開始就對了」，不禁想起從UseCase到領域模型曾是我的一大瓶頸。也許會有人覺得奇怪，這中間不就是名詞轉化為類別，動詞轉化為函式…。我只能說絕不僅是如此，這裏就借用邱老師書上第一個使用者案例，概說一下我的想法。驗證失敗：累積5次登入失敗，即鎖定，並出現請會員主動聯絡系統管理員的訊息. BR3：會員累積5次登入失敗，即鎖定該會員帳號。只要登入成功，即失敗次數歸零. 取自四色原型的觀念，模型必須區分靜態與動態。像PPT這種靜態的物件其屬性應該很少需要修改，所以登入的資訊不適合與會員放於一塊，所以拉出一個較為動態的物件MemberLogin，較為適當。取自DDD的觀念，規則最好可以獨立成Spec物件，這樣設計時自然會變成可動態抽換，而且說不定日後鎖定的規則不是5次，或再加上間隔時間的限制也說不定。 MemberLoginStatus，也許最後設計時只是個字串、長整數、enum之類，但為了分析上的清晰，我還是傾向將它獨立成類別。先來看一半的ER Model。UsersGroups就是Role，伴隨著自身關聯構成Role Hie...再來看另一半的ERMo...

<META> KEYWORDS

1 skip to main

2 skip to sidebar

3 火星紀事

4 usecase到領域建模

5 使用者案例

6 用例名稱：會員登入

7 啟動者：會員

8 支援者：

9 主要流程：

10 會員輸入電郵與密碼

CONTENT

Page content here

KEYWORDS ON PAGE

skip to main,skip to sidebar,火星紀事,usecase到領域建模,使用者案例,用例名稱：會員登入,啟動者：會員,支援者：,主要流程：,會員輸入電郵與密碼,系統確認會員身分之後，出現歡迎訊息,替代流程：,資料不完整：客戶端提醒會員填入資料，直到資料完整才傳送到伺服端,企業規則：,br1：以會員電郵做為會員代號,br2：密碼採用md5儲存,br4：一個人只能申請一個會員身分,議題與其他：,帳號密碼變更是否為一使用者案例,領域模型,最後的模型圖如下：,張貼者：,hugo,沒有留言

CONTENT-TYPE

utf-8

GOOGLE PREVIEW

火星紀事 | marscommentary.blogspot.com Reviews

https://marscommentary.blogspot.com

最近拜讀邱郁惠老師的大作「學會UML/OOAD，這樣開始就對了」，不禁想起從UseCase到領域模型曾是我的一大瓶頸。也許會有人覺得奇怪，這中間不就是名詞轉化為類別，動詞轉化為函式…。我只能說絕不僅是如此，這裏就借用邱老師書上第一個使用者案例，概說一下我的想法。驗證失敗：累積5次登入失敗，即鎖定，並出現請會員主動聯絡系統管理員的訊息. BR3：會員累積5次登入失敗，即鎖定該會員帳號。只要登入成功，即失敗次數歸零. 取自四色原型的觀念，模型必須區分靜態與動態。像PPT這種靜態的物件其屬性應該很少需要修改，所以登入的資訊不適合與會員放於一塊，所以拉出一個較為動態的物件MemberLogin，較為適當。取自DDD的觀念，規則最好可以獨立成Spec物件，這樣設計時自然會變成可動態抽換，而且說不定日後鎖定的規則不是5次，或再加上間隔時間的限制也說不定。 MemberLoginStatus，也許最後設計時只是個字串、長整數、enum之類，但為了分析上的清晰，我還是傾向將它獨立成類別。先來看一半的ER Model。UsersGroups就是Role，伴隨著自身關聯構成Role Hie...再來看另一半的ERMo...

INTERNAL PAGES

marscommentary.blogspot.com

1

火星紀事: 八月 2009

http://marscommentary.blogspot.com/2009_08_01_archive.html

前面提到了角色的設計，我們來看另一種設計方法。這應該是Peter Coad大師在書上提過的作法，只是我沒看過書就是了。 PersonRole roles = new List. Public string Name{get;set;}. Public string Address{get;set;}. Public string Tel{get;set;}. Public void AddRole(PersonRole role). T () where T:PersonRole. Foreach(PersonRole role in roles). 依據Matin Fowler大師的建議，替PersonRole加上HasType這個方法，日後我們的角色如果成長成一顆繼承樹時(Sequenal Roles)，就會很有用。例如專任教師、科任教師的父角色都是教師，而教師的父角色可能是教職員工，這裏就可以寫些判斷的方法。 Public abstract class PersonRole. Public bool HasType T (). Public class Customer : PersonRole.

2

火星紀事: 七月 2008

http://marscommentary.blogspot.com/2008_07_01_archive.html

NET界的PetShop有兩款，一款是微軟出的PetShop，目前到4.0。一款是IBatis.NET出的NPetShop。NPetShop出的，比較符合OO的精神，適合拿做為四色原型分析的範例。這次就從Accounts下的類別，重新分析。原來的設計是這樣的。 Account與Address，一個Account連結一個Address。Account代表的當然是會員，至於Address代表地址。來考慮Account，讀過四色原型分析都知道，Party是一個重要的原型，泛指所有的人員組織，第一個想法就是建立一個Party來取代 Account。再來Account與Party不可能是等值的觀念。能參加購物的，就假定只有會員(Member)。Member與Party也不是等值的觀念，Member只是Party的子集。那Account與Member的觀念等值嗎? 有時是等值，有時不等值。如果一個會員一組帳號，那就是等值。如果一個會員擁有多組帳號，那就不等值。不如把這個觀念拆開獨立。訂閱：文章 (Atom).

3

火星紀事: 五月 2011

http://marscommentary.blogspot.com/2011_05_01_archive.html

最近拜讀邱郁惠老師的大作「學會UML/OOAD，這樣開始就對了」，不禁想起從UseCase到領域模型曾是我的一大瓶頸。也許會有人覺得奇怪，這中間不就是名詞轉化為類別，動詞轉化為函式…。我只能說絕不僅是如此，這裏就借用邱老師書上第一個使用者案例，概說一下我的想法。驗證失敗：累積5次登入失敗，即鎖定，並出現請會員主動聯絡系統管理員的訊息. BR3：會員累積5次登入失敗，即鎖定該會員帳號。只要登入成功，即失敗次數歸零. 取自四色原型的觀念，模型必須區分靜態與動態。像PPT這種靜態的物件其屬性應該很少需要修改，所以登入的資訊不適合與會員放於一塊，所以拉出一個較為動態的物件MemberLogin，較為適當。取自DDD的觀念，規則最好可以獨立成Spec物件，這樣設計時自然會變成可動態抽換，而且說不定日後鎖定的規則不是5次，或再加上間隔時間的限制也說不定。 MemberLoginStatus，也許最後設計時只是個字串、長整數、enum之類，但為了分析上的清晰，我還是傾向將它獨立成類別。先來看一半的ER Model。UsersGroups就是Role，伴隨著自身關聯構成Role Hie...再來看另一半的ERMo...

4

火星紀事: 六月 2008

http://marscommentary.blogspot.com/2008_06_01_archive.html

IBatis.NET的功用，較之nHibernate實在相差甚遠。它只是協助你把查出來的資料，組成物件而已。而查詢資料的SQL，很抱歉，請自己設計。較之nHibernate一切包的好好的，理論上只要設計好物件，再透過nH產生的資料庫，是不必管SQL語法的長像的。兩者的優缺點是看各人的需求的，如果資料庫沒有設計的夠OO，用IBatis是比較靈活的。當然，如果從頭到尾都是OO思考，用nH是可以享受設計一次，觀念一致的系統。先去下載 http:/ ibatis.apache.org/. 下載最新版的DataMapper，我下載的是IBatisNet.DataMapper-bin-1.6.1.zip，把它解開。示範的資料庫是SQLLite，所以要去 http:/ sqlite.phxsoftware.com/. 下載Sqllite的ADO.NET Driver，我下載的是SQLite-1.0.48.0-setup.exe, 執行並安裝它。 Dao是撈物件的介面，參考加入IBaitsNet.Common、IBaitsNet.DataMapper。 TypeAlias alias ="Account" ty...

5

火星紀事: 一月 2008

http://marscommentary.blogspot.com/2008_01_01_archive.html

建立Domain Model時，最令人頭痛的莫過於它建立的準則是什麼。有如在OOD時，如果沒有Design Pattern，設計也會漫無目標，人言人殊。坊間討論OOA的書不少，但涉及Domain Model的部份時，總是輕輕帶過，或者寫不出一個像樣的準則。現實世界是非常複雜的，沒有適當的準則，單憑萬物皆物件，並沒有太大的幫助。討論Domain Model的建立過程，我發現有兩本書值得借鏡。一本是盛名已久的Analysis Pattern，一本則是Java Modeling in Color With UML。AP是各種領域塑模的心血結晶，但JMCU是建立一套推論的準則。而四色分析正是JMCU的特色。在各式的企業概念中，歷經長久的分析，可以歸類成幾種型態，象徵更抽象的概念。 Party是一種人地物(party, place, or thing)的抽象概念。 Role代表Party參予MI時的角色。即使是同一個Party但參予MI時，所使用的Role必然是有差異的。 OO的大師Peter Coad對顏色有異乎常人的喜好，所以就把色彩設計上去了。在蒐集了大量生理資料後，接下來是進行資料的歸...

UPGRADE TO PREMIUM TO VIEW 14 MORE

TOTAL PAGES IN THIS WEBSITE

19

OTHER SITES

marscomedy.mobi

marscomedy.mobi - Registered at Namecheap.com

This domain is registered at Namecheap. This domain was recently registered at Namecheap. Please check back later! This domain is registered at Namecheap. This domain was recently registered at Namecheap. Please check back later! The Sponsored Listings displayed above are served automatically by a third party. Neither Parkingcrew nor the domain owner maintain any relationship with the advertisers.

marscomic.com

Mijndomein

Dit domein is geregistreerd door een klant van. Spaties en leestekens zijn niet toegestaan in domeinnamen. Domeinnamen mogen alleen bestaan uit letters en cijfers.

marscomindia.com

Index of /

Proudly Served by LiteSpeed Web Server at www.marscomindia.com Port 80.

marscomlab.com

마스컴 MKT Lab

marscommedia.com

Marscom Television

Marscom Media - the world of Media creation and production. The world is at your fingertips. Marscom will help you to create, edit and/or produce your desired multimedia story,. To enable you to present it to the world. Film, Television and Multimedia Productions. Marscom Media is integrated with Marscom Television, producing multimedia for over 25 years.

marscommentary.blogspot.com

火星紀事

最近拜讀邱郁惠老師的大作「學會UML/OOAD，這樣開始就對了」，不禁想起從UseCase到領域模型曾是我的一大瓶頸。也許會有人覺得奇怪，這中間不就是名詞轉化為類別，動詞轉化為函式…。我只能說絕不僅是如此，這裏就借用邱老師書上第一個使用者案例，概說一下我的想法。驗證失敗：累積5次登入失敗，即鎖定，並出現請會員主動聯絡系統管理員的訊息. BR3：會員累積5次登入失敗，即鎖定該會員帳號。只要登入成功，即失敗次數歸零. 取自四色原型的觀念，模型必須區分靜態與動態。像PPT這種靜態的物件其屬性應該很少需要修改，所以登入的資訊不適合與會員放於一塊，所以拉出一個較為動態的物件MemberLogin，較為適當。取自DDD的觀念，規則最好可以獨立成Spec物件，這樣設計時自然會變成可動態抽換，而且說不定日後鎖定的規則不是5次，或再加上間隔時間的限制也說不定。 MemberLoginStatus，也許最後設計時只是個字串、長整數、enum之類，但為了分析上的清晰，我還是傾向將它獨立成類別。先來看一半的ER Model。UsersGroups就是Role，伴隨著自身關聯構成Role Hie...再來看另一半的ERMo...

marscommodities.com

Mars Commodities

We are committed to provide the best trading experience to our clients. We strive to provide the fastest. Possible and totally transparent. Trading and execution to our clients. Our research team work constantly towards. Providing technical and fundamental research. On various commodities, to. Enable both retail and corporate investors, to make better Investment. And trading decisions and enjoy the benefits of. Sebi Reg. No. INZ000035738. Membership No.: MCX-16060. Nice Blue Theme by.

marscommons.cobot.me

MaRS Commons - Cobot

marscomms.co.uk

Welcome to Mars Communications Ltd

Mars Communications Ltd is an established telecommunications company. Mars specialise in a range of Premium Rate, Carrier Grade Voice and Mobile Communications Services. Registered in England - Company No: 6478834. Registered Address - Forest House, Forest Road, Ilford, Essex IG6 3HJ, United Kingdom.

marscommsolutions.com

Who we are - MarscomM SolutionS

Call us at 44 7980 124403 with any questions or to schedule an appointment. Script type="text/javascript" src="https:/ platform.linkedin.com/badges/js/profile.js" async defer /script. MarscomM SolutionS Limited is a firm of Chartered Certified Accountants. Based in Slough (West London) we work through a network of accounting and tax firms across Europe, US and Asia Pacific to meet our client's requirements. Please visit Our Services. To find our product offering. Company accounts and self assessment.

marscommunication.blogspot.com

Mars Communication

Dienstag, 30. Juni 2009. Phoenix und ich hatten ja im Prinzip den gleichen Job, nämlich den, nachzuweisen, dass sich Wasser am Mars befindet und demnach Leben möglich ist. Obwohl Phoenix die Kommunikation zur Erde mittlerweile beinahe zur Gänze abgebrochen hat, haben wir beschlossen zumindest zeitweise gemeinsam das Missionsziel zu verfolgen und ab und an mit einem neuen Ergebnis zu beeindrucken. Ein bisschen zu bemitleiden sind natürlich die anderen Roboter auf die wir hier ab und an treffen, sie haben ...