1. 4. UML

2. CPSC 333: Foundations of Software EngineeringJ. Denzinger 4.1. Motivation The Unified Modeling Language tries to integrate older approaches Developed by Rational (CASE tool) they hired Booch, Rumbaugh, Jacobsen Standardized at version 1.1 by the OMG (Object Management Group) Supported by almost all OO CASE tools … but with some limitations … Currently it is at version 1.4 (OMG working on 2.0)

3. CPSC 333: Foundations of Software EngineeringJ. Denzinger Goals of UML Provide users with ready-to-use, expressive visual modeling language to develop and exchange meaningful models. Provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular languages and processes. Provide formal basis for understanding the modeling language. Encourage the growth of the OO tools market. Support higher-level development concepts such as collaborations, frameworks, patterns and components. Integrate best practices.

4. CPSC 333: Foundations of Software EngineeringJ. Denzinger UML has 9 kinds of diagrams  Class Diagram  Object Diagram  Component Diagram  Deployment Diagram  Use Case Diagram  Sequence Diagram  Collaboration Diagram  Statechart Diagram  Activity Diagram Structural Diagrams Behavioral Diagrams

5. CPSC 333: Foundations of Software EngineeringJ. Denzinger 4.2. Structural diagrams 4.2.1. Class diagram Central for OO modeling Shows static structure of the system Types (!) of objects Static relationships (see next lecture)  Association (e.g.: a company has many employees)  Generalization (subtypes) (e.g.: an employee is a kind of person)  Dependencies (e.g.: a company is using trucks to ship products)

6. CPSC 333: Foundations of Software EngineeringJ. Denzinger Class Set of objects Defines name attributes (optional: type optional: initial value) operations Task startDate: Date = default endDate: Date name setStartDate (d : Date) setEndDate (d : Date) getDuration () : Date

7. CPSC 333: Foundations of Software EngineeringJ. Denzinger Class diagram example Light off( ) on( ) HeaterCooler Environmental Controller define_climate( ) terminate_climate( ) 0..* 1 1 1 1 1 SystemLog display( ) recordEvent( ) Actuator startUp( ) shutDown( ) Temperature generalization aggregation association

8. CPSC 333: Foundations of Software EngineeringJ. Denzinger Three Perspectives We can look at classes from these perspectives: Conceptual (OOAnalysis) Shows concepts of the domain Should be independent from implementation Specification (OODesign) General structure of the running system Interfaces of software (types, not classes) Often: Best perspective Implementation (OOProgramming) Structure of the implementation (classes) Most often used Try to draw from a clear, single perspective

9. CPSC 333: Foundations of Software EngineeringJ. Denzinger Attributes Conceptual: Indicates that customer have names Specification: Customer can tell you the name and set it (short for get/set methods) Implementation: An instance variable is available Customer name address creditRating

10. CPSC 333: Foundations of Software EngineeringJ. Denzinger Operations Services that a class knows to carry out Correspond to messages of the class (or IF) Conceptual level principal responsibilities Specification level public messages = interface of the class Normally: Don’t show operations that manipulate attributes

11. CPSC 333: Foundations of Software EngineeringJ. Denzinger UML syntax for operations visibility name (parameter list) : return-type-expression + assignAgent (a : Agent) : Boolean visibility: public (+), protected (#), private (-)  Interpretation is language dependent  Not needed on conceptual level name: string parameter list: arguments (syntax as in attributes) return-type-expression: language-dependent specification

12. CPSC 333: Foundations of Software EngineeringJ. Denzinger Operations vs. Responsibilities Conceptual: Operations should specify responsibilities, not IF, e.g.: The Customer specifies the Orders The Orders list the Customer * 1 Order dateReceived isPrepaid number : String price : Money Responsibilities - lists the customer UML 1.3 Specific (similar to CRC Cards) Customer name address Responsibilities - specifies orders

13. CPSC 333: Foundations of Software EngineeringJ. Denzinger Class versus type Type protocol understood by an object set of operations that are used Class implementation oriented construct implements one or more types In Java a type is an interface, in C++ a type is an abstract class UML 1.3 has the > stereotype and the lollipop

14. CPSC 333: Foundations of Software EngineeringJ. Denzinger Interfaces in UML (1) Stereotype > InputStream {abstract} OrderReader Data InputStream Realization Dependency Generalization > DataInput close()

15. CPSC 333: Foundations of Software EngineeringJ. Denzinger Interfaces in UML (2) OrderReader Data InputStream Dependency DataInput Interface Lollipops (“short-hand notation”)

16. CPSC 333: Foundations of Software EngineeringJ. Denzinger 4.2.2. Systems and subsystems System Design

17. CPSC 333: Foundations of Software EngineeringJ. Denzinger test status request for alarm notification periodic check-in require for configuration update request for status Control panel subsystem Sensor subsystem Central communication subsystem request for system status specification of type of alarm periodic status check Systems and Sub-Systems

18. CPSC 333: Foundations of Software EngineeringJ. Denzinger How to break a system into smaller subsystems? Roman principle: Divide & conquer –Split up a large system into manageable parts In structured methods: functional decomposition In OO: Group classes into higher level units Packages (conceptual; at development time) Components (physical; at run time)

19. CPSC 333: Foundations of Software EngineeringJ. Denzinger Packages General purpose mechanism for organizing elements into groups Package forms a namespace Names are unique within ONE package UML assumes an anonymous root package Resource Pool

20. CPSC 333: Foundations of Software EngineeringJ. Denzinger Package vs. Component Packages Conceptual structuring of system model Source code structure Components “Physical and replaceable part of the system that conforms to and provides the realization of a set of interfaces”, e.g.:  COM+ components, Java Beans, …  source code files  Documents

21. CPSC 333: Foundations of Software EngineeringJ. Denzinger 4.2.3. Component diagrams Component representation resourcePool.java buglist.dll Realizes: BugList FilteredList System::kernel.dll {version=1.23} path name

22. CPSC 333: Foundations of Software EngineeringJ. Denzinger Example Diagram

23. CPSC 333: Foundations of Software EngineeringJ. Denzinger Components vs. classes Both have names and realize interfaces Class logical abstraction Attributes and operations Component Physical thing that exist on machines Physical packaging of logical things (classes, interfaces, …) Only has operations (only reachable thru its IF)

24. CPSC 333: Foundations of Software EngineeringJ. Denzinger Components and interfaces IFs used in all component-based OS-facilities (COM+, CORBA, EJB) ProjectMgt.javaresourcePool.java ResourcePool ResourcePool = import interface for ProjectMgt.java ResourcePool = export interface for resourcePool.java Dependency Interface Realization

25. CPSC 333: Foundations of Software EngineeringJ. Denzinger Alternative representation ProjectMgt.javaresourcePool.java ResourcePool = import interface for ProjectMgt.java ResourcePool = export interface for resourcePool.java Dependency Realization > ResourcePool addEmployee()

26. CPSC 333: Foundations of Software EngineeringJ. Denzinger 4.2.4. Deployment diagrams Show physical relationship among software & hardware components Show where components of a distributed system are located

27. CPSC 333: Foundations of Software EngineeringJ. Denzinger Deployment diagrams (2) Nodes: Computational units (most often: Hardware) Connections: Communication paths over which the system will interact Client TCP/IP Server

28. CPSC 333: Foundations of Software EngineeringJ. Denzinger Nodes and components Account Server Deploys AccountDB.java AccountMgt.java Account Server AccountMgt.javaAccountDB.java

29. CPSC 333: Foundations of Software EngineeringJ. Denzinger Kiosk Account Server Kiosk 0..* 1 1 SalesTerminal