UML

1. UML Unified Modeling Language Based on:UML Distilled Martin Fowler

3. What is UML ? • Modeling language, not a method • Mainly graphical notation used to express the design • Proposed OMG standard • Several techniques: • iterative development • patterns : to describe the key ideas • class diagrams : what kind of abstractions were made • interaction diagrams : key behaviors of the system • use cases : communication with the domain experts • snapshot of one aspect of your system • sum of all use cases is the external picture of your system • activity diagrams

4. Development Process

5. Development Process • Iterative and incremental development process • software developed and released in pieces; • construction phase consists of many iterations, each of them builds production quality software , tested and integrated, that satisfies a subset of the requirements; • each iteration contains the usual life cycle phases. • Iterations could also take place in the other phases. Inception Elaboration Transition Construction 1 2 3 ...

6. 1. Inception • Can be short or can take months • vague idea of functional specifications and feasibility study • e.g. we are going to build the next-generation customer support system for our company. We intend to use object-oriented technology to build a more flexible system that is more customer-oriented, specifically , one that will support consolidated customer bills. • Roughly work out the business case for the project. • Cost/benefit analysis • get a sense of the project’s scope • estimation of the size • In most cases a few days work.

7. 2. Elaboration Inception Elaboration Transition • Better understanding of the problem • What are you actually going to build? • How are you going to build it? • What technology are you going to use? • Risk management • Requirements risks: build the right system • Technological risks: experience with the used technology • Skills risks: is the required staff available? • Political risks Construction 1 2 3 ...

8. Requirement Risks • Tools for requirement gathering • use cases: basis of communication between sponsors and developers in planning the project • conceptual domain model: the world that the computer system is supporting (functions, vocabulary, … ), high level, no details • analysis model: only in larger projects, to explore the consequences of the external requirements • design model: realization of the information in the domain objects and the behavior in the use cases • adds classes to actually do the work • provides a reusable architecture for future extensions • Incremental ( no waterfall approach) • class diagrams: to capture the business language • activity diagrams: describing the workflow of the business • interaction diagrams

9. Technological Risks • Build prototypes that try out the pieces of technology you planned to use • fast evolving technology • high risk in linking the components of a design together • architectural design decisions • special attention to distributed systems • Risks • What happens if a piece of technology doesn’t work ? • What if we can’t connect two pieces of the puzzle ? • What is the likelihood of something going wrong ? • Used techniques • Class diagrams, package diagrams, deployment diagrams

10. Skills Risks • Lack of experience and training • Apply immediately by building prototypes • Organize project discussions • Pattern community http://st-www.cs.uiuc.edu/users/patterns/patterns.html

11. Baseline Architecture Result of the Elaboration (±20% of total project time) • List of use cases • domain model • technology platform Planning • Users: level of priority for each use case • Developers: consider architectural risk for each use case • Developers: commitment schedule

12. 3. Construction Construction builds the system in a number of iterations • each iteration is a mini-project • analysis, design, coding, testing and integration for each use case assigned to the iteration • testing is a continuous process • no code should be written before you know how to test it • write the test immediately • keep test code forever • unit tests (white box) and system tests(black box) • Iterations are both incremental and iterative • incremental in function • iterative in terms of the code base: refactoring (to avoid code degeneration)

13. Refactoring • Software entropy • original structure disappears after subsequent modifications • redesign cause short-term pain for longer-term gain • Refactoring • is a term to describe redesign techniques • will not change the functionality of your program • it changes the internal structure to make it better understandable • changes are small steps (rename a method, move a field, …)

14. Refactoring • Refactoring is made easier by the following steps: • do not refactor and add functionality at the same time • prepare good tests before you start refactoring • keep the steps small • You should refactor when: • if it seems difficult to add new functionality • when you have difficulties in understanding the code

15. Documentation in Construction 1. One or two pages describing a few classes in class diagrams 2. A few interaction diagrams to show how the classes collaborate 3. Some text to pull the diagrams together 4. State diagram if a class has a complex life cycle 5. Patterns to capture the basic ideas

16. Patterns • Look at the result of the process • They describe common ways of doing things • It is much more than a model • it must include the reason why it is the way it is • it is a solution to a problem • patterns must make the problem clear • explain why it solves the problem • explain under what circumstances it solves the problem • Information about patterns • http://st-www.cs.uiuc.edu/users/patterns/patterns.html • http://c2.com/ppr/index.html

17. 4. Transition • Things that should not be done early • e.g. optimization • During transition there is no development to add functionality • There is development to fix bugs Inception Elaboration Transition Construction 1 2 3 ...

19. Use Case Diagrams Set Limits Example : Update Accounts Analyze Risk “uses” Accounting system Valuation “uses” Price Deal Trading Mgr Capture Deal Trader Actor “extends” Capture deal Limits Exceeded Salesperson Use Case

20. Class Diagram:Typical example Multiplicity: many-valued Order Customer Multiplicity mandatory Class dateReceived Is prepaid number:string price: Money Name Address * 1 Dispatch( ) Close( ) CreditRating : string Association Generalization 1 Constraint (If Order.customer.creditRating is “poor” then Order.isPrepaid must be true) Corporate Customer Personal Customer Role Name Sales rep. Line items Employee contactName creditRating creditLimit CreditCard# 0..1 * * Order Line Multiplicity: optional Quantity:int Price:Money IsSatisfied Remind ( ) billForMonth {creditRating() ==“poor”} Product * 1

21. Interaction: Sequence Diagram An Order Entry Window An Order an Order Line A Stock Item Prepare ( ) * Prepare ( ) Object check ( ) Message Condition [check=“true”] remove ( ) Iteration needs ToReorder ( ) Self- Delegation Return a Reorder Item New Object’s lifeline [check=“true”] new a Delivery Item Creation

22. State Diagram Example: An Order start action /get first item [All items checked && all items available] Get next item [not all items checked] Checking do/check item Dispatching do/initiate delivery event Activity [All items checked && some items not in stock] Delivered Item received [all items available] Item received [some items not in stock] transition Waiting Delivered Self transition state

23. Example of Activity Diagram Guard Person Find Beverage [no cola] [no coffee] Synchronization bar Decision activity [found coffee] [found cola] Put coffee in filter Add water Get cups Get can of cola Activity Put Filter Turn on machine ^coffeePot.TurnOn Brew coffee End Light goes out Pour coffeee Drink beverage