A Gentle Introduction to Object-Oriented Software Engineering using UML

1. A Gentle Introduction toObject-Oriented Software Engineering using UML Ugur Dogrusoz Associate Professor, Computer Eng Dept,Bilkent University, Ankara, Turkey Computer Eng Dept, Bilkent Univ

2. Software Engineering Economies of all developed nations are dependent on software More and more systems are software controlled Software engineering is concerned with theories, methods and tools for professional software development Expenditure on software represents a significant fraction of GNP in all developed countries Computer Eng Dept, Bilkent Univ

3. Software Costs Often dominate computer system costs On a PC often greater than the hardware cost It costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs. Software engineering is concerned with cost-effective software development. Computer Eng Dept, Bilkent Univ

4. Objectives • Appreciate Software Engineering • SE is an engineering discipline: analyze, design, and then implement • Build complex software systems in the context of frequent change • Understand how to • produce a high quality software system within time and budget while dealing with complexity and change • Acquire technical knowledge (main emphasis) • Acquire managerial knowledge Computer Eng Dept, Bilkent Univ

5. Why Object-Oriented Approach? • As opposed to procedural/functional/imperative approach • Each object (modeled after its real-life equivalent) has certain • properties and • responsibilities • OO software = interacting collection of objects • Abstraction, encapsulation, reuse, maintenance Computer Eng Dept, Bilkent Univ

6. SE Methodologies • Every software needs • Analysis (what to do) • Design (how to do) • Implementation & Testing • Process/algorithm used for development • Waterfall • Prototyping • Iterative • Incremental • XP (eXtreme Programming) • ... Computer Eng Dept, Bilkent Univ

7. Modeling • To understand • real-life system to be automated (model it “as is”) • software system to be built (model it “as you want it to be”) • Same idea as • blueprints for building bridges, houses, etc. • layouts for manufacturing VLSI chips Computer Eng Dept, Bilkent Univ

8. Modeling • Textual (e.g. long textual descriptions or X3D) or visual/graphical (e.g. sketches or flowchart) • UML (Unified Modeling Language) is a visual modeling language to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development • Helps you model both application and software domains! Computer Eng Dept, Bilkent Univ

9. OO Analysis & Design w/ UML Requirements Elicitation & Analysis System & Object Design Implementation & Testing • Disclaimer: • Do not expect every software to be developed using the same methodology / process described here! • Not necessarily even when software is built in OO manner using UML! Computer Eng Dept, Bilkent Univ

10. OO Analysis w/ UML • Requirements elicitation: • Definition of the system in terms understood by the customer (“Requirements specification”) • Analysis: • Definition of the system in terms understood by the developer (Technical specification, “Analysis model”) Computer Eng Dept, Bilkent Univ

11. OO Analysis w/ UML Problem Statement Requirements Elicitation Use Case Diagrams Non-functional Req. Functional Model Sequence Diagrams Analysis Class Diagrams State Diagrams Analysis Object Model Dynamic Model Activity Diagrams System Design Computer Eng Dept, Bilkent Univ

12. OO Analysis w/ UML: sample project Computer Eng Dept, Bilkent Univ

13. OO Analysis w/ UML: sample project Computer Eng Dept, Bilkent Univ

14. Analysis: Requirements Elicitation • Bridging the gap between end user and developer: • Questionnaires: Asking the end user a list of pre-selected questions • Task Analysis: Observing end users in their operational environment • Scenarios: Describe the use of the system as a series of interactions between a concrete end user and the system • Use cases: Abstractions that describe a class of scenarios Computer Eng Dept, Bilkent Univ

15. Analysis: Requirements Elicitation • Functional requirements • Students should be able to add/drop courses • Professors should be able to view course rosters • ... • Non-functional requirements • All user inputs should be acknowledged within 1 second • A system crash should not result in data loss • Constraints (pseudo-functional requirements) • The implementation language must be Java Computer Eng Dept, Bilkent Univ

16. Analysis: use case scenarios • Cases in which a software system is used • Use case instances = scenarios • Example scenario: • “A student logs on to CRS successfully. CRS displays a list of options, from which he selects to add a new course to take. He is presented with a list of available sections, from which he makes his choice and successfully adds the new course.” • instance of use case “Add Course” Computer Eng Dept, Bilkent Univ

17. Analysis: use case descriptions • Find all the use cases in the scenario that specify all instances of “how to add a course” • Describe each of these use cases in more detail • Participating actors • Describe the entry condition • Describe the flow of events • Describe the exit condition • Describe exceptions • Describe nonfunctional requirements Computer Eng Dept, Bilkent Univ

18. Analysis: use case descriptions Use case name: Add Course Participating actors: Student Entry condition: The student has already successfully logged on to CRS Exit condition: The student has successfully added the course to his/her schedule Computer Eng Dept, Bilkent Univ

19. Analysis: use case descriptions • Main flow of events • The student chooses to list the courses available to take • The system lists all such courses • The student makes a selection • The system verifies the student is eligible to take the course and displays the sections available • The student chooses a section • The system adds the student to section roster Computer Eng Dept, Bilkent Univ

20. Analysis: use case descriptions • Alternative flow of events • The student is not eligible to take the desired course (display appropriate message and go to Step 2) • All sections of the course are full (display appropriate message and go to Step 2) • The schedule of selected section conflicts with current schedule of the student (display appropriate message and go to Step 5) Computer Eng Dept, Bilkent Univ

21. Analysis: UML use case diagrams Summary of use case model: relationships between actors and use cases Computer Eng Dept, Bilkent Univ

22. OO Analysis w/ UML Problem Statement Requirements Elicitation Use Case Diagrams Non-functional Req. Functional Model Sequence Diagrams Analysis Class Diagrams State Diagrams Analysis Object Model Dynamic Model Activity Diagrams System Design Computer Eng Dept, Bilkent Univ

23. Analysis: object model • Identify • objects (classes), • properties (attributes) & operations (methods), and • relations between objects (inheritance, composition, etc.) Computer Eng Dept, Bilkent Univ

24. Analysis: object model • Application domain approach • Ask domain experts to identify relevant abstractions • Syntactic approach (Abbot’s technique) • Start with use cases • Analyze the text to identify the objects • Extract participating objects from flow of events • ... Computer Eng Dept, Bilkent Univ

25. Analysis: object types • Entity Objects • Represent the persistent information tracked by the system (Application domain objects, also called “Business objects”) • Boundary Objects • Represent the interaction between the user and the system • Control Objects • Represent the control tasks performed by the system. Computer Eng Dept, Bilkent Univ

26. Analysis: object model • Do a textual analysis (noun-verb analysis) Abbott’s Technique • Nouns are candidates for objects/classes • Verbs are candidates for operations • Their types • Identify real world entities that the system needs to keep track of (Course  Entity Object) • Identify real world procedures that the system needs to keep track of (Scheduler  Control Object) • Identify interface artifacts (Add/Drop Form  Boundary Object). Computer Eng Dept, Bilkent Univ

27. Analysis: object model • Abbott’s Technique • “ ... Professors will be able to access the system to sign up to teach courses as well as recordgrades ...” • “... Course offerings will havea maximum of ten students and a minimum of three students ...” Computer Eng Dept, Bilkent Univ

28. Analysis: UML class diagrams • Class diagrams represent the structure of the system • Used during • analysis to model application domain concepts • system design to model subsystems • object design to specify the detailed behavior and attributes of classes. Computer Eng Dept, Bilkent Univ

29. Analysis: object model for CRS Computer Eng Dept, Bilkent Univ

30. OO Analysis w/ UML Problem Statement Requirements Elicitation Use Case Diagrams Non-functional Req. Functional Model Sequence Diagrams Analysis Class Diagrams State Diagrams Analysis Object Model Dynamic Model Activity Diagrams System Design Computer Eng Dept, Bilkent Univ

31. Analysis: dynamic model • Complements previous techniques of • Application domain analysis • General world knowledge and intuition • Textual analysis of event flow in use cases (Abbot) • Describes components of the system w/ interesting dynamic behavior • Dynamic (vs. static) diagrams: • Sequence diagrams: one per use case scenario • State diagrams: one per object/class • Activity diagrams: one per operation Computer Eng Dept, Bilkent Univ

32. Analysis: UML sequence diagrams Math department agrees in a faculty meeting that Prof. Cengiz is to also teach a section of Math 201, which is offered as two sections. Assuming he’s already logged on, he chooses the option to add a new course to teach. He inputs Math 201. The system checks and finds out that the schedule of section 1 conflicts with other course(s) he is teaching. Luckily, section 2 is unassigned and nicely suits his schedule, for which Cengiz successfully signs up and logs out. Computer Eng Dept, Bilkent Univ

33. Analysis: UML state diagrams Course offerings will have a maximum of ten students and a minimum of three students. A course offering with fewer than three students will be canceled. States and transitions for Section objects/class Computer Eng Dept, Bilkent Univ

34. Analysis: UML activity diagrams A student wants to add a new course. The student fills out the form by specifying the semester, the course to take (department and course number) and the section, to which the student would like to be added. Then, the student clicks the OK button. The system checks whether the particular section is still open for registration and the maximum count hasn’t been reached. If so, the system checks if the particular section of the added course fits the student’s schedule. Add operation is not allowed when there are any conflicts in the schedule. If there is no conflict, the system updates the database and simultaneously notifies the billing system of the change. It then displays an appropriate message. The student may, of course, cancel the add operation at any point during this process. Computer Eng Dept, Bilkent Univ

35. Analysis: user interface • User Interface • Menus and screens/forms/dialogs/windows • Navigational paths between menus and screens • Mock-ups Computer Eng Dept, Bilkent Univ

36. Analysis: report organization Share w/ customer; forms a basis for a contract w/ customer! • Introduction • Current system • Proposed system • Overview • Functional requirements • Nonfunctional requirements • Constraints (“Pseudo requirements”) • System models • ... • Glossary Computer Eng Dept, Bilkent Univ

37. Analysis: report organization For the sake of developers Use Case Diagrams Class Diagrams Sequence, State & Activity Diagrams • ... • System models • Scenarios • Use case model • Object model • Dynamic models • User interface • Glossary Computer Eng Dept, Bilkent Univ

38. Analysis: summary • Application domain is modeled to fully understand the real-life system • “as is” • “as you want it to be” • Resulting model • specifies exactly what the system is going to do • is a contract between developer and customer • is input to design phase Computer Eng Dept, Bilkent Univ

39. OO Design w/ UML • Analysis: focuses on the application domain • Design: focuses on the solution domain • The solution domain is changing very rapidly • Design knowledge is a moving target • what vs. how Computer Eng Dept, Bilkent Univ

40. OO Design w/ UML Analysis Object Model Dynamic Model Deployment Diagrams Class Diagrams System Design Component Diagrams Subsystem Decomposition System Design Object Model Design Goals Object Design Class Diagrams Object Design Model Implementation & Testing Software Computer Eng Dept, Bilkent Univ

41. From analysis to system design Nonfunctional Requirements Functional Model 8. Boundary Conditions 1. Design Goals Initialization Termination Failure Definition Trade-offs Functional Model 2. System Decomposition Dynamic Model Layers vs Partitions Coherence/Coupling 7. Software Control Monolithic Event-Driven Conc. Processes Object Model Dynamic Model 5. Data Management 4. Hardware/ Software Mapping 6. Global Resource Handling 3. Concurrency Persistent Objects Filesystem vs Database Special Purpose Systems Buy vs Build Allocation of Resources Connectivity Identification of Threads Access Control List vs Capabilities Security

42. Design: examples of design goals • Good documentation • Well-defined interfaces • User-friendliness • Reuse of components • Rapid development • Minimum number of errors • Readability • Ease of learning • Ease of remembering • Ease of use • Increased productivity • Low-cost • Flexibility Reliability Modifiability Maintainability Understandability Adaptability Reusability Efficiency Portability Traceability of requirements Fault tolerance Backward-compatibility Cost-effectiveness Robustness High-performance Computer Eng Dept, Bilkent Univ

43. Design: typical tradeoffs A low cost system does not do mucherror checking (e.g. 5.00 or 5,00 Euros). It’d be very difficult to build a real-time game that is portable. Functionality v. Usability Cost v. Robustness Efficiency v. Portability Rapid development v. Functionality Cost v. Reusability Backward Compatibility v. Readability Space v. Speed Computer Eng Dept, Bilkent Univ

44. Design: subsystem decomposition • Subsystem • Collection of classes, associations, operations, events and constraints that are closely interrelated with each other • Great way to handle complexity Computer Eng Dept, Bilkent Univ

45. Design: subsystem decomposition • Service • A set of named operations that share a common purpose • The origin (“seed”) for services are the use cases from the functional model • Services are defined during system design Computer Eng Dept, Bilkent Univ

46. Design: subsystem interface object «Facade» «PackageClass1» «PackageClass2» «PackageClass3» • In a good design • The subsystem interface object describes all the services of the subsystem interface • Realized with the Façade design pattern Computer Eng Dept, Bilkent Univ

47. Design: layers and partitions Layer 1 A:Subsystem Layer 2 C:Subsystem D:Subsystem B:Subsystem Layer3 E:Subsystem F:Subsystem G:Subsystem Partition 1 of Layer 3 Partition 2of Layer 3 Partition 3of Layer 3 Computer Eng Dept, Bilkent Univ

48. Design: layers and partitions • A layer is a subsystem that provides a service to another subsystem with the following restrictions: • A layer only depends on services from lower layers • A layer has no knowledge of higher layers • A layer can be divided horizontally into several independent subsystems called partitions • Partitions provide services to other partitions on the same layer • Partitions are also called “weakly coupled” subsystems. Computer Eng Dept, Bilkent Univ

49. Design: relationships bw subsystems • Layer A “depends on” Layer B (compile time) • Example: Build dependencies (make, ant, maven) • Layer A “calls” Layer B (runtime) • Example: A web browser calls a web server • Mapping of layers to processors is decided during the software/hardware mapping! • Partition relationship • The subsystems have mutual knowledge about each other. A calls services in B; B calls services in A (Peer-to-Peer) • UML convention: dashed vs. solid lines Computer Eng Dept, Bilkent Univ

50. Design: layers and partitions Layer Relationship “depends on” Partition relationship Layer 1 A:Subsystem Layer 2 C:Subsystem D:Subsystem B:Subsystem Layer3 E:Subsystem F:Subsystem G:Subsystem Layer Relationship “calls” Computer Eng Dept, Bilkent Univ