1 / 27

CS427: Software Engineering I

CS427: Software Engineering I. Darko Marinov (slides from Ralph Johnson). Administrative info. HW1 graded Projects http://brain.cs.uiuc.edu:8080/SEcourse/Projects+Fall+06 Keep forming 8-student groups Current group members decide on new members Midterm: confirmed time and room change

september-dunlap
Download Presentation

CS427: Software Engineering I

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. CS427:Software Engineering I Darko Marinov (slides from Ralph Johnson)

  2. Administrative info • HW1 graded • Projects http://brain.cs.uiuc.edu:8080/SEcourse/Projects+Fall+06 • Keep forming 8-student groups • Current group members decide on new members • Midterm: confirmed time and room change • 7pm on Oct 10 (Tue) in 1404 SC (not DCL!) • Makeup exam: 12:30pm on Oct 10 in 1310 DCL • Let us know if you have other conflicts • Samples http://brain.cs.uiuc.edu:8080/SEcourse/Exams+Fall+06 CS427

  3. Topics • Covered • Project initiation and planning • Requirements (use cases) • Design (architecture) • Today: UML introduction • Notations useful for requirements, specification, design, and (potentially) coding CS427

  4. Modeling notations (1) • Used for both requirements analysis and for specification and design • Useful for technical people • Provide a high-level view • Require training • Many notations • Each good for something • None good for everything CS427

  5. Modeling notations (2) • Help developers communicate • Provide documentation • Help find errors (tools check for consistency) • Generate code (with tools) CS427

  6. Unified Modeling Language (UML) • Graphical modeling notations for describing and designing (OO software) systems • 13 kinds of diagrams (in UML 2.0) • Structure • Class diagrams (today) • Behavior • Interaction • Sequence diagrams (today) CS427

  7. UML class diagrams • Formed by merging Booch Diagrams and OMT Object Diagrams • Descendent of Entity-Relationship Diagrams • Describes data and operations CS427

  8. Elements of UML class diagram • Class • Attributes • Operations • Associations • Multiplicity • Direction/aggregation • Generalization CS427

  9. Familiar(?) example domain

  10. Problem source • From a Design Fest at OOPSLAhttp://designfest.acm.org/Problems/HealthClaims/HealthClaims_96.htm • In addition to system description, has three use cases • Central concept: claim CS427

  11. Claim class diagram CS427

  12. Inheritance CS427

  13. Multiplicity • 0..1 or 0..N is optional • 1 is mandatory • * is 0..N CS427

  14. OO modeling points • Best objects correspond to real-world entities • Some correspond to actors (adjudicator); they are actually interfaces to the actors • Some correspond to complex processes, but this is an exception; should not be common CS427

  15. Attributes vs. associations CS427

  16. Health claims processing • Receives health claims and supporting documents via many sources: electronically, fax, on paper. • Scanned paper and fax processed by OCR. Documents first subject to form dropout, deskewing, despeckling. • All images are logged to optical disk. CS427

  17. Behavior CS427

  18. OO modeling points • Class names should be nouns • Verbs become operations • Avoid class names ending in “er” CS427

  19. Analysis vs. design • Class diagrams are used in both analysis and design • Analysis - conceptual • Model problem, not software solution • Can include actors outside system • Design - specification • Tells how the system should act • Design - implementation • Actual classes of implementation CS427

  20. Extending class diagrams • No modeling notation can do everything • Modeling notations should be extensible • UML has two techniques • Constraints • Stereotypes CS427

  21. Constraint CS427

  22. Stereotype CS427

  23. Interfaces to other systems CS427

  24. UML sequence diagrams • Model how a set of objects communicate • Describe sequence of events (traces) • A line for each object • Time goes from top to bottom • Arrows represent communication events CS427

  25. Sequence diagram for claim CS427

  26. Class diagram • Central model for OO systems • Describes data and behavior • In UML, used along with Use Cases and Packages for analysis • Also used to describe implementation • Don’t confuse analysis and implementation! • Separate “what” from “how” CS427

  27. Next: Analysis and design in RUP • Read chapters 5-8 of “UML Distilled: Third Edition” (“Class Diagrams: Advanced”, “Object Diagrams”, “Package Diagrams”, “Deployment Diagrams”; 2nd edition: chapters 6-7 and first part of 10) • Chapters 3-4 listed for today • Chapters 1-2 and 9 listed earlier CS427

More Related