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.  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. InceptionElaborationTransition 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  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 InceptionElaborationTransition 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 InceptionElaborationTransition Construction 1 2 3...

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

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

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

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

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