1 / 86

A Gentle Introduction to Object-Oriented Software Engineering using UML

A Gentle Introduction to Object-Oriented Software Engineering using UML. Ugur Dogrusoz Associate Professor, Computer Eng Dept, Bilkent University, Ankara, Turkey. Software Engineering. Economies of all developed nations are dependent on software More and more systems are software controlled

tilly
Download Presentation

A Gentle Introduction to Object-Oriented Software Engineering using UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related