UML Overview Based in parts on UML Distilled from Martin Fowler - PDF document

USC C S E USC - Center for Software Engineering UML Overview Based in parts on ‘UML Distilled’ from Martin Fowler Alexander Egyed CSCI 612 March, 1999 USC Outline C S E USC - Center for Software Engineering • UML Views • Diagrams – Use Case Diagrams – Class Diagrams – Interaction Diagrams – Package Diagrams – State Diagrams – Activity Diagrams – Deployment Diagrams • Some Conclusions 1

USC Modeling and UML C S E USC - Center for Software Engineering Why Modeling? - Programs become more complex - Failures more costly - Edit-and-Compile cycle not very efficient Why New Models for OO? - Paradigm shift from Functional Oriented Design to Object-Oriented Design => functional modeling leads to functional decomposition - New Concepts such as Inheritance , Polymorphism , Data/Behavior Encapsulation , etc. USC UML History C S E USC - Center for Software Engineering OMT 1995 1996 1997 (Rumbaugh and others) UML UML UML 1.1 0.8 0.9 (OMG Standard) Booch UML OOSE 1.3 (Jacobson and others) (beta) 1999 2

USC UML 1.1 OMG Standard C S E USC - Center for Software Engineering UML is a language for specifying, constructing, and documenting software systems: - General Purpose Modeling Language - Merges Modeling Element from Booch, Rumbaugh, Jacobson and others - Object-Oriented Analysis and Design - Graphical Notation supporting numerous diagrams - Extensible Notation (Stereotypes) - Extensible Semantics (Object Constraint Language) UML is backed by numerous software producers such as Digital, HP, IBM, Oracle, Microsoft, Unisys, and others USC UML 1.1 OMG Standard C S E USC - Center for Software Engineering However, ... - Semantics often ambiguous (only the UML Notation Meta-Model well defined) - As of yet there is no tool that supports all of UML (not even Rational Rose) - Uses both OO and functional development concepts Nevertheless, ... - Common model eases communication and interaction - More precise meaning (semantics) can be added (customized) 3

USC Views in UML C S E USC - Center for Software Engineering Analysis Prototype and Interface Simulation (Dialog) Requirements Use Cases and Interaction Data Flow Classes and Physical Data Deployment Objects Architecting and High-Level Design Analysis State Transition Implementation Architecting and High-Level Design Low-Level Design Low-Level Design USC Components and Connectors C S E USC - Center for Software Engineering Components: - Classes, Objects, and Packages - States and Activities - Actors and Use-Cases Connectors: - Basically three types: Communication (control and data), Containment, Attachment - Restricted in what types of components they link - First class citizens 4

USC Outline C S E USC - Center for Software Engineering • UML Views • Diagrams – Use Case Diagrams – Class Diagrams – Interaction Diagrams – Package Diagrams – State Diagrams – Activity Diagrams – Deployment Diagrams • Some Conclusions USC Use-Case Diagrams C S E USC - Center for Software Engineering - Capture those parts of the system that are visible to the outside (e.g. users or other systems). - A use case is usually about a concrete goal or task from the user’s point of view - Use-Cases may give no feedback in terms of complexity or system decomposition => mainly an analysis method. 5

USC Use-Case Diagram C S E Stereotype (between guillemots) USC - Center for Software Engineering <<uses>> <<uses>> File Admit Patient administrative staff Discharge Patient patient database Human Actor System doctor Prescribe Treatment Actor <<extends>> Procedure Fails nurse Track Treatment Procedures facilities database Schedule Resources dietician Use-Case kitchen Order Meals USC Outline C S E USC - Center for Software Engineering • UML Views • Diagrams – Use Case Diagrams – Class Diagrams – Interaction Diagrams – Package Diagrams – State Diagrams – Activity Diagrams – Deployment Diagrams • Some Conclusions 6

USC Class Diagrams C S E USC - Center for Software Engineering - Describe the static relationship of classes in a system. These relationship must always be true. - Classes often represent physical or otherwise tangible entities but this must not always be true, either. - Classes are probably the most misunderstood and misused elements in OO design. Frequently used Connectors: - Associations - Aggregation - Generalization USC Class Diagram C S E USC - Center for Software Engineering Association Transaction 1..* 1..* 1 1 Customer 1..* 1..* 1 1 1..* 1..* 1..* 1..* Posts has Is at 1 1 1..* 1..* 1 1 0..1 0..1 Is at Area Branch Accoun t BankCard 1..* 1..* 1..* 1..* 1 1 0..* 0..* 1..* 1..* Aggregation SavingsAccount Generalization CheckingAccount CollegeAccount PBAAccount CurrentAccount Class 7

USC Class Diagrams C S E USC - Center for Software Engineering Classes are usually the most central OO development elements since they reflect the actual implementation the closest -> this may have negative side effects. Need to distinguish three types of classes: - Conceptual Classes: Should capture domain entities with no regard to the actual implementation. - Design Classes: Should capture design entities without overly committing to implementation details - Implementation Classes: Should capture the physical model (e.g. strongly influenced by programming language) USC Domain Classes C S E USC - Center for Software Engineering P a tie nt na m e Dom a in Mode ls s how re a l-world a ddre s s obje cts a nd the re la tions hips Hos pita l S SNO be twe e n the m ins ura nce info a dm it pa tie nt() S ta ff Vis it Re cord dis cha rge pa tie nt() a dm is s ion da te re le a s e da te room num be r m e dica tions te s ts s che dule d Me dica l Sta ff Admin S ta f f Ope ra tions S ta ff Me dica l His tory Fa cilitie s dia gnos tic info te s t re s ults X-ra ys Bill Ope ra ting Room La bora tory Pha rm a cy Em e rge ncy Room Kitche n 8

USC Design Classes C S E USC - Center for Software Engineering Patient Visit Record name admission date address release date SSNO room number insurance info medications 1..1 1..1 1..1 1..1 tests scheduled admit patient() discharge patient() 0..* 0..* Account Medical History status diagnostic info amount 1..1 1..1 1..1 1..1 Bill test results X-rays 0..* 0..* create() modify() Hospital delete() Access Pre:{amount=0} USC Implementation Classes C S E USC - Center for Software Engineering nvo_SystemManager nvo_SecurityManager dso_Exception CheckAccess() -iu_SecurityManager CheckAccess() GetSubSystem() CheckConnectionStatus() +idso_ nvo_WindowManager SetSubSystem() RaiseException() HandleException() CheckUnsavedData() -iu_ExceptionManager OpenWindow() nvo_ExceptionManager nvo_SessionManager -iu_SessionManager RaiseException() GetUserID() LogException() GetSubSystem() CheckConnectionStatus() w_Logon Account Medical History Open() Patient status cb_OK-Click() name diagnostic info amount address test results X-rays SSNO create() insurance info modify() delete() admit patient() discharge patient() 1..1 1..1 Visit Record w_ExceptionHandling 1..1 1..1 admission date w_HospitalWindow release date ExceptionHandlingSelection() room number Open() medications SetAccess() tests scheduled CheckUnsavedData() 9

USC Advanced Concepts in Classes C S E USC - Center for Software Engineering - Constraint Rules: e.g. Precondition {Amount = 0}. Also useful to model post conditions and invariants (Design by Contract) - Multiple Classifications Doctor Surge on Fe m a le Pe rs on The ra pis t Doctor s e x Ma le {mandatory} role pa tie nt Nurse Pa tie nt USC Advanced Concepts in Classes C S E USC - Center for Software Engineering Ma na ge r - Dynamic Classifications Fe m a le <<dynamic>> Job Engine e r P e rs on s e x Ma le <<static>> S a le s m a n - Aggregation and Composition: Aggregation is the part-of relationship. Easy? Consider: Employee part-of Company, Engine part-of Car, etc. Sounds right but may not be true! P oint Composition (from a wt) Circle P olygon (from a wt) Style Instance of Point belongs to only one object and it dies with it Aggregation 10

USC Advanced Concepts in Classes C S E USC - Center for Software Engineering Person - Derived Associations and Attributes date-of-birth / age - Interfaces and Abstract Classes (generalization vs. realization) PC Window <<abstract>> Window X11 MyApp toFront() toBack() Mac realize - Reference Classes vs. Value Classes => not all classes are equal (many customers, one date) - Classification vs. Generalization (is-a is dangerous) 1) Peter is-a Doctor; 2) Doctor is-a Employee; 3) Doctor is-a Profession => Peter is-a Profession? USC Advanced Concepts in Classes C S E USC - Center for Software Engineering - Qualified Associations Order used to Product to identify Order Line Order Order Line Product line item am ount : Num ber 0..1 0..1 Is categorized by - Association Classes employer Person Company Person Skills 0..* 0..* 0..1 0..1 0..* 0..* 0..* 0..* Employment Competency period Implies only one instance of Employment per Association of Person and Company => Person employed by same company at different times? 11