1. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 1 February 20, 2004 Lecture 4: Introduction to Software Analysis and Design - UML Prof. Kazimierz Subieta Polish-Japanese Institute of Information Technology Institute of Computer Science, Warsaw, Poland subieta@ipipan.waw.pl http://www.ipipan.waw.pl/~subieta System Engineering and Databases

2. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 2 February 20, 2004 Content  UML overview  Use Case diagrams  Class diagrams  UML class diagrams - notation summary  Sequence diagrams  Collaboration diagrams  Statechart diagrams  Activity diagrams  Package diagrams  Component diagrams  Deployment diagrams  UML diagrams in Analysis and Design Acknowledgment: The material has been compiled from many Internet sources. It has no commercial purpose. Special thanks to anonymous authors of the Rational Software Corporation, who were the original authors of many of the presented slides.

3. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 3 February 20, 2004 UML - a Notation for Analysis and Design Use case diagrams Static structure diagrams: class diagrams object diagrams package diagrams Behavior diagrams: Interaction diagrams: sequence diagrams collaboration diagrams statechart diagrams activity diagrams Implementation diagrams: component diagrams deployment diagrams The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software- intensive system. [http://www.rational.com/uml] Kinds of diagrams within UML

4. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 4 February 20, 2004 Use Cases One of the most fundamental problems in software engineering is determining the requirements of a system. The notion of use-cases, introduced by Jacobson, is an excellent approach. The use-case approach requires the analyst to determine all the potential actors involved in a system. Actors are external to the system and make use of it. An actor is typically a person, but may be a third-party organization or another computer system. One person may in fact be multiple actors, say a shop assistant may be a customer of the same shop at another time. We model actors, not individuals. An actor makes use of a system in different ways. Each of these ways is known as a use-case. A use-case may involve a number of actors, just as an individual actor may make use of several use-cases.

5. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 5 February 20, 2004 Use Case Diagrams - Basic Notation Use Case Actor “Uses” and “extends” relationships Note Taking Code Review Design Review Technical Review >

6. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 6 February 20, 2004 Use Case Diagram Determining limits Risk analysis Determining prices Violating limits Estimation of profits Updating accounts Calculating estimates Merchandise Director Trader Salesman Accounting System «extends» «uses»

7. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 7 February 20, 2004 Use cases: description and documentation Obligatory points: For each use case: Short description of a use case: purpose, motivation, importance; Description of interaction with actors: when it takes place and which data are sent, event flow between an actor and a use case, event flow within a use case. For each actor: Short description of an actor; Description of interaction with use cases Description of «uses» and «extends» relationships between use cases; Description of generalization relationships between actors (e.g. a secretary is an employee), The general use case diagram.

8. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 8 February 20, 2004 Use cases: description and documentation Non-obligatory (but recommended) points How and when a use case starts and terminates? A rough layout of the user interface; Special non-functional requirements, for instance performance constraints, the max elapsed time necessary for answer, standards, etc.; Exceptions during performing a use case; Objects from the business domain which participate in a use case; Which, how, what for, and when data stored in a system are required for a use case? Which, how, what for, and when data are stored in a system by a use case? Interaction diagrams for each actor (in the form of UML sequence diagrams).

9. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 9 February 20, 2004 Verification of use cases through interaction with the customer The use case diagram (plus documentation) should be prepared in terms understandable for our customer (client or interviewer). It should be a basis of interaction with the customer and verification of the collection of functional requirements. The verification process should lead to the wide acceptance of the system goals, assumptions and functions from the side of the customer. The goals of the interaction are the following: Explaining if the use case diagram covers all functions of the system Explaining if the use case diagram covers all actors which can use the system Explaining which functions are redundant or overlapped Explaining which actors are redundant or overlapped

10. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 10 February 20, 2004 Verification of use cases through interaction with the customer (cont.) Minimizing the number of functions Minimizing the number of actors Refining the interaction between actors and use cases by creating more general and/or more specific actors and more general/specific use cases (for instance, having actors secretary and salesman we can determine an actor employee, which will have access to some basis system services) Refining the diagram by separating “regular” uses cases and “exceptional” use cases; then connecting exceptional uses cases by the relationships «extends» Refining the diagram by recognizing reusable (common) functions and then, connecting the reusable functions by the relationship «uses»

11. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 11 February 20, 2004 Class Diagrams A representation of the types of objects in the system and the various kinds of static relationships that exist among them. It serves as the framework for the system design. Object - an identified, intelligent component of information system capability. Domain objects represent "things" in the world (entities). Capability - behavior that the object can perform, typically requiring variables (data attributes) and methods (procedural code). Class - a collection of objects having the same capabilities. Association - a relationship among objects Subtype Specialization (Subclasses) - subset of a class that extends its capabilities Constraint - a rule defining legal states of objects, classes, relationships, and subtypes.

12. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 12 February 20, 2004 Classes, Attributes, Operations Class Name attribute : type operation() Class operation(parameter : type) : return_class public abstract class Account { protected double m_CurrentBalance; public void credit(double amount) { } public void debit(double amount) { } } Account m_CurrentBalance : double credit(amount : double) : void debit(amount : double) : void Mapping to Java:

13. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 13 February 20, 2004 Specialization Employee Person Assistant Secretary Professor Programmer Inheritance: specialized classes inherit all properties of all the super- classes. ( Professor has all properties of Employee and Person.) Substitutability: an object from a specialized class can be used in all the contexts, where an object defined by its super-classes can be used. (a Professor object can be used in all contexts where a Person object can be used.)

14. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 14 February 20, 2004 Relationships between Classes public class Person { public Company employer; } public class Company { public Vector employee; } Position PersonCompany * 0..1 +employee+employer Associations, Association roles Position PersonCompany

15. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 15 February 20, 2004 UML class diagrams - notation summary AB B is a specialization of A A is a generalization of B AB A is associated with exactly one B AB A is an aggregate of Bs AB A contains B AB A is associated with many (zero or more) Bs * AB A is associated with minimum m and maximum n Bs; n can be *. m..n AB Class C represents the properties assigned to the relationship between A and B. C Customer Class (name only) Class with attributes Customer Name Address Customer Name Address Customer Verify GiveDiscount Class with operations (methods) Customer Name Address Verify GiveDiscount Class with attributes and operations (methods) AB Association between A and B is qualified by attribute c. c AB Association name c between A and B is to be read from A to B. c

16. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 16 February 20, 2004 UML class diagram example - abstract Service Agent Car Loan Home Loan Business Loan Loan History has a works for for a has a uses works with makes secures * * * * Customer Collateral Loan Institution Payment * 0..1

17. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 17 February 20, 2004 UML class diagram example - more detailed Professor 0..4 Person name IDNumber Parttime yearsInAttendance Fulltime gradYear Course 1 3..* 1 Classification maxCourseLoad 1 Student studentID * Teaches Attends

18. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 18 February 20, 2004 Sequence Diagrams controllerserviceentitystorage create() edit(entity) set() validate() add(entity) update(entity) Sequence diagrams present the flow of messages between instances in time. One can immediately see in what order messages are sent because time is an explicit, vertical dimension. Each instance is represented as a vertical line.

19. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 19 February 20, 2004 Collaboration diagrams Collaboration diagrams emphasize relationships (associations) between objects and show message flow between objects. They present subsets of class diagrams together with arrows showing associations and message flow. Numbers attached to messages determine their order.

20. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 20 February 20, 2004 Collaboration diagrams - example Registration Form Delete Form Course Offering 1: enter id 2: verify id 3: delete course 4: within add/drop period 5: display 6: enter number 7: delete student(id) 8: close form 9: close form Delete Course Scenario : Student

21. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 21 February 20, 2004 Statechart Diagrams - Example Statechart diagrams define possible states and transitions between them. Positive BalanceNegative Balance Empty doTransaction( amount ) doTransaction( amount )[ amount < 0 ] openAccountcloseAccount doTransaction( amount ) doTransaction( amount )[ amount < 0 ] doTransaction( amount )[ amount > 0 ]

22. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 22 February 20, 2004 Statechart Diagram - Example Initialization do: Initialize course offering data Open entry: Register student exit: ^CourseRoster.AddStudent (student) Closed do: Finalize course Canceled add student / set count = 0 ^CourseRoster.Create cancel ^CourseRoster.Delete cancel [ count = 10 ] Course Offering add student[ count < 10 ]

23. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 23 February 20, 2004 Activity diagrams Activity diagrams are syntactic variants (particular cases) of state transition diagrams or classical control flow diagrams (flowcharts). They show sequencing dependencies between tasks. Some tasks must be done sequentially, others can be done in parallel i.e., an activity diagram shows the workflows of a system. An activity diagram provides detailed view of processes. A black bar denotes splitting a control flow into several parallel activities or merging several parallel control flows into a single activity.

24. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 24 February 20, 2004 Activity diagrams -example Create curriculum Select course to teach Assign professor to courses Create catalog Place catalog in bookstore Mail catalog to students Open registration [No] [Yes] All profs assigned?

25. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 25 February 20, 2004 People Package diagrams Show how classes can be divided into logical packages. They also show high-level relationships between packages. University Artifacts Interfaces DatabaseMFC Classes global Error Handling global

26. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 26 February 20, 2004 Component diagrams Show dependencies between run-time components of the software. They should be used during implementation of the software. Professor.exe Course.dll Database.dll ProfessorCourseOptions AddACourse ProfessorInformation Run-time of Professor.exe

27. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 27 February 20, 2004 Deployment diagrams Registration Database Dorm Main Building Library professor.exe student.exe A deployment diagram models physical platforms and network connections used by system. It matches CPUs to software components. Arbitrary icons can be used to represent nodes.

28. 3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 4, Slide 28 February 20, 2004 UML diagrams in Analysis and Design User requirements Use Case diagrams User interface screens Class diagrams Physical data structures Relational database schema Object-relational database schema C++, Java, etc. class declarations Implementation code State diagrams Activity diagrams Sequence diagrams Collaboration diagrams Component diagrams Deployment diagrams testing Obligatory Optional Package diagrams