1. 01 November 2007Kaiser: COMS W4156 Fall 20071 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/

2. 01 November 2007Kaiser: COMS W4156 Fall 20072 Reprise: What is UML? UML = Unified Modeling Language A standard language for specifying, visualizing, constructing and documenting software artifacts Standardized by Object Management Group (OMG) Uses mostly graphical notations (blueprints) Helps project teams communicate, explore potential designs, and validate the requirements and architectural design of the software system

3. 01 November 2007Kaiser: COMS W4156 Fall 20073 Our Focus: the Language  Unified Modeling Language Language = syntax + semantics –Syntax = rules by which language elements (e.g., words) are assembled into expressions (e.g., phrases, clauses) –Semantics = rules by which syntactic expressions are assigned meanings

4. 01 November 2007Kaiser: COMS W4156 Fall 20074 The basic building blocks (syntax) of UML are: –Model elements (classes, interfaces, components, use cases) –Relationships (associations, generalization, dependencies) –Diagrams (class diagrams, use case diagrams, interaction diagrams) Simple building blocks are used to create large, complex structures Building Blocks

5. 01 November 2007Kaiser: COMS W4156 Fall 20075 Types of UML Diagrams Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction –Use Case –Interaction –State –Structural –Implementation

6. 01 November 2007Kaiser: COMS W4156 Fall 20076 Structural Modeling Define the architecture Used to model the “things” that make up the system Model class structure and contents Emphasizes the structure of objects, including their classifiers, attributes, operations, and relationships including dependencies

7. 01 November 2007Kaiser: COMS W4156 Fall 20077 Structural Diagrams Show a graph of elements connected by relationships Kinds –Class diagram: classifier view –Object diagram: instance view Shows the static structures of the system (not dynamic or temporal)

8. 01 November 2007Kaiser: COMS W4156 Fall 20078 Class Diagrams Shows how the different entities (people, things and data) relate to each other A class diagram can be used to display logical classes, not necessarily code classes, which are typically the kinds of things the business people in an organization talk about — rock bands, CDs, radio play; or home mortgages, car loans, interest rates Use domain vocabulary

9. 01 November 2007Kaiser: COMS W4156 Fall 20079 Class Diagram Example

10. 01 November 2007Kaiser: COMS W4156 Fall 200710 Class Notation A class is depicted on the class diagram as a rectangle with three horizontal sections (compartments) The upper section shows the class's name The middle section contains the class's structure or attributes, optionally with initial values The lower section contains the class's operations or behaviors (or "methods") May be abbreviated to show just name, or just name and attributes

11. 01 November 2007Kaiser: COMS W4156 Fall 200711 Class Example

12. 01 November 2007Kaiser: COMS W4156 Fall 200712 Class Diagram Draw a generalization relationship using a line with an arrowhead at the top pointing to the super class, where the arrowhead should a completed triangle Associations –A solid line if both classes are aware of each other –A line with an open arrowhead if the association is known by only one of the classes (pointing to the class known by the other one, i.e., direction of potential navigation) –Optionally label with multiplicity

13. 01 November 2007Kaiser: COMS W4156 Fall 200713 Example Class Diagram Generalization One-way association Two-way association

14. 01 November 2007Kaiser: COMS W4156 Fall 200714 Association Example

15. 01 November 2007Kaiser: COMS W4156 Fall 200715 Generalization Example

16. 01 November 2007Kaiser: COMS W4156 Fall 200716 Core Elements

17. 01 November 2007Kaiser: COMS W4156 Fall 200717 Core Relationships

18. 01 November 2007Kaiser: COMS W4156 Fall 200718 Implementation Class Diagrams Can also be used to show implementation classes, which are the things that programmers typically deal with An implementation class diagram will probably show some of the same classes as the logical classes diagram The implementation class diagram won't be drawn with the same attributes, however, because it will most likely have references to things like Vectors and HashMaps May add compartments such as responsibilities and exceptions, even gist of method body May indicate attribute and operation visibility: public, private, protected, package

19. 01 November 2007Kaiser: COMS W4156 Fall 200719 Example Implementation Class

20. 01 November 2007Kaiser: COMS W4156 Fall 200720 Example Class Detail + = public - = private # = protected ~ = package visibility

21. 01 November 2007Kaiser: COMS W4156 Fall 200721 Method Body Example

22. 01 November 2007Kaiser: COMS W4156 Fall 200722 Generalization Often represents inheritance at implementation class level Abstract class names given in italics Possibly multiple inheritance Possibly multiple inheritance hierarchies emanating from same base class Separate vs. shared target formats

23. 01 November 2007Kaiser: COMS W4156 Fall 200723 Generalization Example Equivalent Forms

24. 01 November 2007Kaiser: COMS W4156 Fall 200724 Generalization Example

25. 01 November 2007Kaiser: COMS W4156 Fall 200725 Multiple Level Generalization Example

26. 01 November 2007Kaiser: COMS W4156 Fall 200726 Associations Reflect connections, usually implemented as an instance variable in one class Connector may include named roles at each end, cardinality, direction and constraints Self-associations permitted May indicate choice ( xor ) May be N-ary (not just binary) Association classes allow an association connection to have operations and attributes

27. 01 November 2007Kaiser: COMS W4156 Fall 200727 Association Example

28. 01 November 2007Kaiser: COMS W4156 Fall 200728 Association Examples

29. 01 November 2007Kaiser: COMS W4156 Fall 200729 Association Class Example

30. 01 November 2007Kaiser: COMS W4156 Fall 200730 Ternary Association Class Example

31. 01 November 2007Kaiser: COMS W4156 Fall 200731 Aggregations Aggregations are a stronger form of association between a whole and its parts Drawn with a diamond next to the class representing the target or whole (parent) open vs. closed diamond indicates usage vs. containment semantics Containment may be indicated by composition rather than relationship lines

32. 01 November 2007Kaiser: COMS W4156 Fall 200732 Aggregation Example

33. 01 November 2007Kaiser: COMS W4156 Fall 200733 Aggregation Example

34. 01 November 2007Kaiser: COMS W4156 Fall 200734 Composition Example

35. 01 November 2007Kaiser: COMS W4156 Fall 200735 Dependencies Dependencies are a weaker form of association without semantic knowledge Often used early in the design process where it is known that there is some kind of link between two elements, but it is too early to know exactly what the relationship is Later in the design process, dependencies may be replaced with a more specific type of connector Shown with a dashed line (e.g., from client to supplier) > on line specifies kind (stereotype) of dependency, e.g., >, >, etc.

36. 01 November 2007Kaiser: COMS W4156 Fall 200736 Dependencies Example

37. 01 November 2007Kaiser: COMS W4156 Fall 200737 Dependencies Example

38. 01 November 2007Kaiser: COMS W4156 Fall 200738 Interfaces All interface operations are public and abstract, and all interface attributes must be constants By realizing an interface, classes are guaranteed to support a required behavior, which allows the system to treat non-related elements in the same way – that is, through the common interface While a class may only inherit from a single super-class, it may implement multiple interfaces May be drawn in a similar style to a class, with operations specified Or may be drawn as a circle with no explicit operations detailed (when drawn as a circle, realization links to the circle form of notation are drawn without target arrows)

39. 01 November 2007Kaiser: COMS W4156 Fall 200739 Interface Example

40. 01 November 2007Kaiser: COMS W4156 Fall 200740 Interface Realization Example

41. 01 November 2007Kaiser: COMS W4156 Fall 200741 Adapted from Fig. 23 [EJB 2.0]. Interface Example

42. 01 November 2007Kaiser: COMS W4156 Fall 200742 Types and Implementation Classes Example

43. 01 November 2007Kaiser: COMS W4156 Fall 200743 Object Diagrams Refer to a specific instance Special case of a class diagram Does not show operations but may show runtime state Object names are underlined and may show the name of the classifier from which the object is instantiated May compose multiple specific instances May be drawn as glyphs

44. 01 November 2007Kaiser: COMS W4156 Fall 200744 Class vs. Object Diagram Example

45. 01 November 2007Kaiser: COMS W4156 Fall 200745 Run-time State Example

46. 01 November 2007Kaiser: COMS W4156 Fall 200746 More Object Examples

47. 01 November 2007Kaiser: COMS W4156 Fall 200747 Composite Objects Example

48. 01 November 2007Kaiser: COMS W4156 Fall 200748 When to Model Structure Adopt an opportunistic top-down interleaved with bottom-up approach to modeling structure –Specify the top-level structure using “architecturally significant” classifiers and model management constructs (subsystems) –Specify lower-level structure as you discover detail wrt classifiers and relationships

49. 01 November 2007Kaiser: COMS W4156 Fall 200749 Implementation Diagrams Additional structural modeling (beyond classes, interfaces and objects) Show aspects of model implementation, including source code structure and run- time implementation structure Kinds –Package diagram –Component diagram –Deployment diagram

50. 01 November 2007Kaiser: COMS W4156 Fall 200750 Package Diagrams Used to reflect the organization of packages and their elements Provide a visualization of the namespaces Elements contained in a package share the same namespace, therefore must have unique names Drawn as folders, with tabs at the top; the package name is on the tab or inside the rectangle Dotted arrows show dependencies - one package depends on another if changes in the other could possibly force changes in the first

51. 01 November 2007Kaiser: COMS W4156 Fall 200751 Package Diagrams Packages may be imported or nested A > connector between two packages defines an implicit generalization between elements in the source package and elements with the same name in the target package The target package need not contain elements with same names as all source package elements

52. 01 November 2007Kaiser: COMS W4156 Fall 200752 Package Diagram Example nested package

53. 01 November 2007Kaiser: COMS W4156 Fall 200753 Component Diagrams Describes the software components that make up the system Provides a physical view of the system Shows the dependencies that the software has on the other software components (e.g., software libraries) in the system A component is illustrated as a large rectangle with two smaller rectangles on the side, lollipops represent interfaces Dashed lines with arrows between components indicate dependencies

54. 01 November 2007Kaiser: COMS W4156 Fall 200754 Component Examples

55. 01 November 2007Kaiser: COMS W4156 Fall 200755 Component Diagram Example

56. 01 November 2007Kaiser: COMS W4156 Fall 200756 Component Diagram Example with Labeled Dependencies

57. 01 November 2007Kaiser: COMS W4156 Fall 200757 Deployment Diagram Visualizes the physical architecture and the deployment of components on that hardware architecture Shows how a system will be physically deployed in the hardware environment, distribution of components across the enterprise Its purpose is to show where the different components of the system will physically run and how they will communicate with each other

58. 01 November 2007Kaiser: COMS W4156 Fall 200758 Deployment Diagram Notation Includes the notation elements used in a component diagram, plus adds the concept of a node A node represents either a physical machine or a virtual machine node (e.g., a mainframe node) To model a node, simply draw a three- dimensional cube (or box) with the name of the node at the top of the cube Use the naming convention [instance name] : [instance type] (e.g., "w3reporting.myco.com : Application Server")

59. 01 November 2007Kaiser: COMS W4156 Fall 200759 Deployment Diagram Example

60. 01 November 2007Kaiser: COMS W4156 Fall 200760 UML is effective for modeling large, complex software systems It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects It can specify systems in an implementation- independent manner 10-20% of the constructs are used 80-90% of the time Structural modeling specifies a skeleton for the structural elements that supply the behavior (sequence, state, activity diagrams) and implement the use cases (use case diagrams) Implementation diagrams extend structural modeling to source code and run-time structure Summary

61. 01 November 2007Kaiser: COMS W4156 Fall 200761 http://www.uml.org/ — The official UML Web sitehttp://www.uml.org/ http://argouml.tigris.org/ — Information on Argo UML, an open source UML modeling tool built in Javahttp://argouml.tigris.org/ http://uml.sourceforge.net/index.php — Information on Umbrello UML Modeller, an open source UML modeling tool for KDEhttp://uml.sourceforge.net/index.php http://www-306.ibm.com/software/rational/uml/ - IBM’s UML resource center (IBM bought Rational in 2002)http://www-306.ibm.com/software/rational/uml/ Resources

62. 01 November 2007Kaiser: COMS W4156 Fall 200762 First Iteration Demos Due! October 30 th – November 8 th Extra credit on per-day-early sliding scale Only team members present for the demo (for CVN virtually present) will receive credit – 10% of final grade No “presentation” needed, but be prepared to answer questions, show your code, and let the TA enter input to your system

63. 01 November 2007Kaiser: COMS W4156 Fall 200763 Upcoming Deadlines First iteration final report due Friday November 9 th, must respond to any “issues” that arose during demoFirst iteration final report Midterm Individual Assessment posted Friday November 9 th Midterm Individual Assessment due Friday November 16 th 2 nd iteration starts

64. 01 November 2007Kaiser: COMS W4156 Fall 200764 Second Iteration Add extensive error checking and exception handling Black box unit testing and white box statement coverage Semi-formal code inspection Security and stress testing Seeking volunteer teams to do code inspections (Tue 27 Nov and Thu 29 Nov) and final demos (Tue 4 Dec and Thu 6 Dec) in class

65. 01 November 2007Kaiser: COMS W4156 Fall 200765 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/