An overview of UML

The objectives of OOAD create codes in good architecture, easily maintainable create reusable codes (via inheritance) modeling software before building it (models can be validated, verified….) delay implementation stage and find any potential problems/design flaws before implementation change the way of software development OOAD documents are used as a blue print, serving as a guidelines for implementation. 減少摸石頭過河過程中錯誤所帶來的金錢與時間延遲 OOAD documents serve as a communication tool between managers/programmers

Why is UML important? Architects design buildings. Builders use the designs to create buildings. The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade.

OOAD standard language UML UML (Unified Modeling Language) It is intended to become the standard visual models for software engineering (千呼萬喚始出來的一種軟體工程語言) It is not only used in OOAD but can be used in other software applications where programs are not OO( 可視為軟體的工程圖標準（不見得只是對物件導向程式有用） 由物件導向學界的三位巨頭成果結合而成 3 amigos Grady Booch (Rational Software) Jim Rumbaugh (GE) Ivar Jacobson In practice, UML is gradually accepted as a standard visual models. Many researches show that it is useful in practice. (近年來的推廣，業界接受度很高，多項研究調查顯示UML在業界實用上有用) It is an informal language, but useful. Although it is called a LANGUAGE, actually it is a set of diagram (visual models) (雖然它稱為語言，事實上只是一組標準圖形表示方式)

UML’s goal In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design.

UML ─ A design and analysis language for communication Have you ever read other people’s source code? Have you ever need to understand an existing system? from source code -- a bad start from specification (規格書） -- 見林不見樹

NOTES UML is just a tool, like OOPL，not a methodology You understand UML X=> you know OOAD (知道UML語言，不代表你會OOAD) Just like a mechanic can understand a blueprint but does not mean he can design one. (正如同懂OOPL不代表你會寫出真正的OO程式) Now, writing OOP mostly use UML as a standard tool (但是進行OOAD現在都會用UML語言來做為工具（早期沒有標準化之前，各種圖示都有人使用） More UML diagrams are released for specific application domain (基本上UML含有OOAD必要的功能，但是它是一套適用任何類型軟體工程的語言，例如real time 系統。（有些功能正不斷的擴充中）)

When to use it In a forward engineering, Specs-> modeling -> coding ->…. 在需求規格制訂後，採用UML工具進行建構一個model然後分析與設計。然後可以利用分析所得到的UML分析資料，輸入UML 工具，產生程式碼模版讓程式設計人員進行細節加工。分析過程中的UML文件可以視為工程藍圖，以及說明文件。 In a backward engineering （亡羊補牢） Code -> UML diagrams : use UML for documentation purpose (在程式寫出來之後，利用軟體工具或人工，將程式的UML架構圖繪製出來，補寫文字，作為說明文件，只是一個亡羊補牢的措施)

How to use it 在各式各樣的軟體工程工具裡面繪製UML圖,並產生程式碼模版 Other pure drawing tools Rational rose Borland together ArgoUML ……. Other pure drawing tools Visio ……

What is analysis and design? If you don’t feel learning something solid in the class, don’t blame me. Design can be hard ! analysis and design is a software engineering process aimed for large or project based software development. In small programs (involving one or two persons) -> understand -> think -> coding In large project, you are in big trouble if you think you are smart and you can remember and manage anything in your brain

The right time to get training of SE or OOAD many-year experienced programmers EMBA (enterprise Master of Being an Asshole) not ALL the MBA degree can attract business man. Typical MBA non-experience graduates Overwhelm the students with case studies learn valuable experience from case studies avoid mistakes from case studies However, no way this can replace in-field experience MSE degree in CMU Advanced OOA?

Is everything must be OO? Not quite true OOA is used to structure a system, not to derive algorithms to solve problems. Implementing algorithms/systems which are still in research object-orientedly could be waste of time Who knows what will come next? Component techniques? Software architecture?

UML history terms need to know OOPSLA (Object-oriented programming, systems, languages, and applications) OMG (object management group) Smalltalk

History of UML key methodologists protest standardization OOPSLA 94 Old joke: what is the difference bewteen a methodologist and a terrorist? Answer, you can negotiate with a terroist OOPSLA 94 Booch and Rumbaugh merge their method and declare “the method war is over – we won” other suggest anti-booch coalition 1996 UML 1.0 announced now UML 1.3

UML, a modeling language UML define a notation and a meta-model How strictly should you stick to the modeling language? CASE tool: more strict to get acceptable codes for communication purpose: you can have a little more leeway

Why you are using UML to do Analysis and Design Communication allow you to communicate certain concepts more clearly than the alternatives Natural language is too imprecise code is precise but too detailed You are suggested to use UML to highlight important details avoiding lose sight of the forest for the trees on a large project serving as a brief document of the system

Why you are using UML to do Analysis and Design learning OO Object languages allow advantages but don’t provide them. by Tom Hadfield Communicating wirh domain experts the biggest challenge of development build the right system (just like in exam, you answer the right answer)

 Jacobson’s Three Types Interface Objects, Advantages: Other Interfaces Outputs User Interface Object Behavior Object Attributes Object Classes

 Jacobson’s Three Types Control Objects: Sometimes we find a method (subroutine, function) that uses data, and calls other methods, from many different objects and classes. These methods don’t easily fit or don’t logically belong in any of our entity classes or interface classes.

5.2. Classes and Classification Additional Data-world Classes Abstract Classes Often added to take advantage of inheritance and polymorphism Sometimes we invent an “artificial” superclass To make use of some common attributes or behavior

Discussion 分析的目的是為了要讓程式碼寫出來能夠充分的應付未來的變化。讓程式能夠順利的演化 好的分析不容易，大規模的分析通常必須由有經驗的人為之（可以讓叫沒經驗的程式員自行進行負責的小模組內的分析） 壞的分析等於浪費時間，反而另程式開發時程蹉跎 有分析通常比沒分析來的好很多，因為分析的過程中逼迫主事者了解絕大部分的細節，考慮所有可能發生的狀況，就算分析隨著程式設計而修改可以將風險降到最小,而不致延遲到 implementation

Discussion 好的分析！＝好的效能 通常具備好結構的軟體會具備有較差的效能，因為多了許許多多物件的新增，物件之間的呼叫。所以在 design 階段，有時候為了效能，又會合併class 要程式員寫乾淨，好的程式碼不容易。如果能先行分析，可以逼迫程式設計人員按照架構寫出乾淨好維護的程式碼 好的分析可以造就好的分工,teamwork 成功的分析就是要能夠嗅出未來軟體可能演化的部分與方向。 針對任何案子，沒有所謂完美的分析。好壞只是程度上的差別，純粹看主事者要應付程式演化的問題到什麼程度 好的分析一定要落實到程式碼，沒有大量實做經驗背景的人所做的分析可能無法達到

Discussion 在你的軟體發展過程中，你認為花在分析與設計的時間要多少？ What type of software you build (what kind of market you are in)? e.g. there is no need for analysis for most research Is evolveability very important in your area? is technology changing very fast in your area? How long is your design/code typically out of date and thrown away? what is the scale of your software? what is the total cost of your software? Are documentation/process important in your company? Have your programmers high transition rate? How much quality you care? 6 month design/planning, 3 month coding, 3 month testing

An brief introduction of UML No single diagram are capable of describing software. ( 軟體工程幾十年的重要體認就是我們沒有辦法用單一種的圖像來表示軟體) There are several aspects of software. Must be dealt by several kind of diagrams. (軟體有許多面向，需要以不同的圖形表示方式來解決) Use case diagrams Class diagrams Object diagrams Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Component diagrams Deployment diagrams

Use Case Diagram

class diagram

Sequence diagram

Collaboration diagram

state chart

Activity diagram

package and object diagram

Component and deployment diagram