System Engineering and Databases

1. System Engineering and Databases 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

2. 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. UML - a Notation for Analysis and Design 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] • 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 Kinds of diagrams within UML

4. 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. Use Case Diagrams - Basic Notation “Uses” and “extends” relationships Use Case Actor Design Review <<extends>> <<uses>> Note Taking Technical Review <<extends>> <<uses>> Code Review

6. Use Case Diagram Determining limits Updating accounts Accounting System Merchandise Director Risk analysis «uses» Calculating estimates Determining prices «uses» Estimation of profits Trader Salesman «extends» Violating limits

7. 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. 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. 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. 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. 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. Classes, Attributes, Operations Class Name Account attribute : type m_CurrentBalance : double operation() credit(amount : double) : void debit(amount : double) : void Class Class operation(parameter : type) : return_class Mapping to Java: public abstract class Account { protected double m_CurrentBalance; public void credit(double amount) { } public void debit(double amount) { } }

13. Specialization Person Employee Secretary Professor Assistant 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. Relationships between Classes Person Person Company Company Associations, Association roles Position +employee +employer Position 0..1 * public class Person { public Company employer; } public class Company { public Vector employee; }

15. UML class diagrams - notation summary Customer Name Address Customer Name Address Customer Verify GiveDiscount Customer Name Address Verify GiveDiscount B is a specialization of A A is a generalization of B A B Customer Class (name only) A B A is an aggregate of Bs Class with attributes A B A contains B A is associated with exactly one B A B A is associated with many (zero or more) Bs * A B Class with operations (methods) m..n A is associated with minimum m and maximum n Bs; n can be *. A B Class C represents the properties assigned to the relationship between A and B. A B Class with attributes and operations (methods) C Association between A and B is qualified by attribute c. A B c c Association name c between A and B is to be read from A to B. A B

16. UML class diagram example - abstract 0..1 Collateral Home Loan secures uses Car Loan * * has a Customer Loan Business Loan * * has a for a makes works with Loan History * Payment makes works for Service Agent Institution

17. UML class diagram example - more detailed Person name IDNumber Classification Student Professor maxCourseLoad studentID 1 1 1 3..* Teaches Attends Fulltime Parttime * 0..4 gradYear yearsInAttendance Course

18. Sequence Diagrams 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. controller service entity storage create() add(entity) edit(entity) set() validate() update(entity)

19. 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. Collaboration diagrams - example 2: verify id 4: within add/drop period 1: enter id 3: delete course 9: close form Registration Form : Student 6: enter number 8: close form 5: display 7: delete student(id) Delete Form Course Offering Delete Course Scenario

21. Statechart Diagrams - Example doTransaction( amount ) doTransaction( amount ) doTransaction( amount )[ amount < 0 ] doTransaction( amount )[ amount > 0 ] doTransaction( amount )[ amount < 0 ] doTransaction( amount )[ amount > 0 ] doTransaction( amount )[ amount > 0 ] openAccount closeAccount Statechart diagrams define possible states and transitions between them. Positive Balance Negative Balance Empty

22. Statechart Diagram - Example Course Offering Initialization do: Initialize course offering data add student / set count = 0 ^CourseRoster.Create Open add student[ count < 10 ] entry: Register student exit: ^CourseRoster.AddStudent (student) [ count = 10 ] cancel Closed Canceled do: Finalize course cancel ^CourseRoster.Delete

23. 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. Activity diagrams -example Create curriculum Select course to teach Assign professor to courses All profs assigned? [No] [Yes] Create catalog Place catalog in bookstore Mail catalog to students Open registration

25. Package diagrams MFC Classes global Error People Handling global Database Show how classes can be divided into logical packages. They also show high-level relationships between packages. Interfaces University Artifacts

26. Component diagrams Show dependencies between run-time components of the software. They should be used during implementation of the software. Professor.exe Database.dll Course.dll ProfessorInformation ProfessorCourseOptions AddACourse Run-time of Professor.exe

27. Deployment diagrams 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. Database Registration professor.exe Library Dorm Main student.exe Building student.exe student.exe

28. UML diagrams in Analysis and Design Relational database schema Object-relational database schema C++, Java, etc. class declarations Component diagrams Package diagrams Obligatory Optional User interface screens Deployment diagrams Class diagrams Use Case diagrams User requirements Physical data structures Sequence diagrams Implementation code State diagrams Collaboration diagrams Activity diagrams testing