1 / 89

SE 430 Object Oriented Modeling

SE 430 Object Oriented Modeling. Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30. Administrivia. Comments and feedback Last Assignments Assignment 6 Due tonight Assignment 7 Due November 10, 2016 Critique

wstanley
Download Presentation

SE 430 Object Oriented Modeling

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. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 SE 430: Lecture 9

  2. Administrivia • Comments and feedback • Last Assignments • Assignment 6 • Due tonight • Assignment 7 • Due November 10, 2016 • Critique • Due November 17, 2016 • Term Project • Due November 17, 2015 • Final Examination • November 12 to November 18. SE 430: Lecture 9

  3. Assignment 7 (Due November 10, 2016) Museum Automation Visitor Information Subsystem: Visitor Audit Tracking – Design Class Diagram • Finish the use case realization and make it into a full fledged class diagram. • Deliverables • Design class diagram. • Full and complete glossary for the classes [only]. SE 430: Lecture 9

  4. SE 430 – Class 9 Topic: Design Model • The Design Model • Constructing Design Class Diagrams • Non-Graphical Design Model Documentation • Deployment Diagrams Topic: Architecture • Architectural Patterns • Architectural Patterns for the Assemble Document System • Packages and Implementation Diagrams Reading: • Arlow & Neustadt, Ch.'s 1 esp. p13, 11, 17, 24 • UML Class Diagrams • Walking through a UML Design SE 430: Lecture 9

  5. Thought for the Day "Customers who see a train of ever improving value are less likely to panic or act capriciously." SE 430: Lecture 9

  6. Last Time Topics: • Real Use-Cases • Use-Case Realizations (Design scenarios) • Evolution of the Mixed Information Display Document Assembly Scenario • More on Design – [OO Metrics] SE 430: Lecture 9

  7. Design Model SE 430: Lecture 9

  8. Design Model • Interaction diagrams and design class diagrams comprise the major graphical design model artifacts • Design class diagrams have corresponding non-graphical (text) specifications for all elements: classes, attributes, operations, and associations • Package diagrams address logical packaging and development logistics issues • Deployment diagrams address deployment of physical elements such as components SE 430: Lecture 9

  9. Design Model • Interaction diagrams and design class diagrams comprise the major graphical design model artifacts • Design class diagrams have corresponding non-graphical (text) specifications for all elements: classes, attributes, operations, and associations • Package diagrams address logical packaging and development logistics issues • Deployment diagrams address deployment of physical elements such as components SE 430: Lecture 9

  10. Design Model The first phases of use-case realizations are design scenarios, CRC cards, and sequence diagrams CRC cards are the starting point for capturing class structure in a design class diagram (DCD) The DCD can be iteratively and incrementally constructed during the development of the use case realization SE 430: Lecture 9

  11. When to create design class diagrams • Recall that use-case realizations: • Are design descriptions of one or more scenarios within a use case. • Are represented by interaction diagrams. • Realizations are the launching point for capturing class structure in a full-scale design class diagram (DCD) • In practice, DCD is often constructed in parallel with use-case realizations SE 430: Lecture 9

  12. DCDs and the Design Model • Interaction diagrams and DCDs together comprise the major graphical artifacts of the design model • DCDs are a special case of general UML class diagrams • DCDs have corresponding non-graphical (text) specifications for all DCD elements: classes, attributes, operations, and associations • Package diagrams address packaging and development grouping issues • Deployment diagrams address physical artifact deployment This is the whole thing SE 430: Lecture 9

  13. DCDs and the Design Model Design Modelconsists of: • Interaction Diagrams • Design Class Diagrams • Package diagrams • Deployment diagrams • Glossary • Class specifications • Package specifications This is the whole thing SE 430: Lecture 9

  14. Constructing Design Class Diagrams SE 430: Lecture 9

  15. Characteristics of design classes • A design class acts as a template for producing objects that share common structure and common behavior. • An object is a concrete entity in time and space; a class is not. • A class may behave as an object, in the role of a metaclass. • Example: The Java Integer toString(int i) method. • Entities at very high levels of abstraction are not classes; these are components, class categories, or frameworks. • Examples: Browser, UI packages, Windows & Java Platform. • Inappropriate level of abstraction generally leads to cluttered class interfaces and responsibility ‘bloat.’ SE 430: Lecture 9

  16. Types, specifications, classes, and objects • A type specifies the externally visible interface for an entity, but does not deal with its implementation • A type specification provides a detailed description of a type, including operation contracts, signature details, and invariants • A class represents an implementation of a type specification and acts as an abstract template for producing instances (objects) via constructors • Every object is an instance of a class • A class has zero or more instances Type Uncovered in design scenarios, documented in CRC cards describes Specification Expands on CRC card info to define operation contracts, operation signatures, invariants, etc. Example: Java API docs implements Class Object 1 0..* instance-of SE 430: Lecture 9

  17. Domain vs. Design Diagrams SE 430: Lecture 9

  18. Class Diagrams Design Class Diagrams – are descriptions of software components interacting to provide solutions to problems in the domain. The class diagrams show definitions for software entities rather than real-world concepts. A Class Diagram should have  • Classes • Attributes • Associations • Methods and interfaces with their operations • Attribute type information • Navigability • Dependencies SE 430: Lecture 9

  19. Class Diagrams Foundations needed for creating Design Class Diagrams • Conceptual Model –   • Includes the classes and details added during design • Interaction Diagrams –    • Derived from design scenarios and use case realizations • Include the software classes that   • Participate in the solution and • The methods of classes SE 430: Lecture 9

  20. Class Diagrams Steps to making a Class Diagram • Draw a class diagram that contains all the classes used in an interaction diagram. (Include all attributes from conceptual/domain model) • Add associations necessary to support the required attribute visibility. [From the messages in the interaction diagram.] • Add method names to those classes receiving messages on interaction diagrams. (Method name matches message name) • Copy attributes from associated concepts in the conceptual model. • Add navigability arrows to the associations to indicate direction of attribute visibility. The source class has an attribute which points to the target class • Add type information to the attributes and methods. • Add dependency relationship lines to indicate non-attribute visibility. The source class has parameter visibility to the target class. SE 430: Lecture 9

  21. Design class diagram (DCD) topics • Classes • Attributes • Operations • Dealing with collections • Class relationships • Associations • Navigability • Dependencies • Advanced: Class relationships • Generalization/specialization • Implements • Aggregation • Packages We’ll examine each of these topics in the context of the final version of the Mixed Information Display and Document Assembly scenario. SE 430: Lecture 9

  22. Steps • Identify DocumentAssembly classes • Add DocumentAssembly attributes and operations • Add DocumentAssembly associations, navigability, and dependencies • Add DocumentAssembly generalization and aggregation relationships SE 430: Lecture 9

  23. Mixed information display (MID) DocumentAssembly scenario SE 430: Lecture 9

  24. Document Assembly sequence diagram :Viewer :Directory :Server Redundant argument of self «create» :Document :Pane content(contentList) «create» refresh(self) :Retrieval Agent paneContent(item) Time «create» * [for each content item] retrieve(item) whereis(item) receive(location) request(item) receive(item) receive(item) display(item) destroy(self) * [for each Pane] Redundant argument of self Redundant argument of item SE 430: Lecture 9

  25. Classes: icon, attributes, and operations • Display essential or defining attributes and operations. • Class name, attribute and operation names should be meaningful and unambiguous. • Omitting compartment makes no statement about presence/absence of corresponding elements; empty compartment does. Italicize class or operation name if it is abstract. SE 430: Lecture 9

  26. Classes: icon, attributes, and operations • Abstract classes define an interface but do not provide a complete set of method implementations • Example: Template Method design pattern • Italicize abstract class and method names • UML visibility notation: • + public • - private • # protected • ~ package Italicize class or operation name if it is abstract. SE 430: Lecture 9

  27. Iteration 1: Identify MID (DocumentAssembly) classes and components See note. Class corresponding to requested ‘item’ returned from Server Class corresponding to requested ‘item’ Class corresponding to ‘contentList’ SE 430: Lecture 9

  28. Attributes and operations • Attributes • An attribute represents an intrinsic characteristic of a class • As we have discussed, non-primitive attributes may be represented by an association • Though essential in domain model diagrams, this is rarely done in design class diagrams • Operations • Operations represent the behavior (or services) that an instance of a class is capable of performing. • Operation details —operation signatures, parameter type, return values— evolve throughout analysis and design, from the conceptual through the implementation models. • Example: Start with request(…), evolve through request(displayItem), to request(displayItem, returnRef). SE 430: Lecture 9

  29. Review: Behavior – types of operations • Constructor: Creates an object and optionally initializes its state. • Modifier or mutator: Alters the state of an object. • Selector or accessor: Accesses the state of an object without altering it. • Iterator: Permits all parts of an object to be accessed in some well-defined order. • Destructor: Frees the state of an object and/or destroys the object itself. SE 430: Lecture 9

  30. Review: Behavior – types of operations • Two species of operations: • Instance. Most common. Behavior varies from instance to instance in response to operation, based on the state of the instance. • Example: Java Integer toString() method. Integer aInt = new Integer(42); String foo = aInt.toString(); • Class. Define invariant behavior for any instance. Behaves as a stand-alone procedure, e.g. static methods in Java. • Example: Java Integer toString(int i) method. String foo = Integer.toString(42); SE 430: Lecture 9

  31. Iteration 2: Add MID (DocumentAssembly) attributes and operations P a n e D o c u m e n t « c o m p o n e n t » « c o m p o n e n t » D i r e c t o r y S e r v e r « p r o v i d e d i n t e r f a c e » - p a n e L i s t : L i s t - i t e m : C o n t e n t I t e m - « p r o v i d e d i n t e r f a c e » + w h e r e I s ( C o n t e n t - - p a n e L a y o u t S p e c i f i c a t i o n + r e q u e s t ( C o n t e n t - I t e m S p e c i f i c a t i o n ) - c o n t e n t I t e m : I t e m S p e c i f i c a t i o n ) D i s p l a y O b j e c t + c o n t e n t ( L i s t ) « r e q u i r e d i n t e r f a c e » « r e q u i r e d i n t e r f a c e » + r e c e i v e ( L o c a t i o n ) + r e c e i v e ( D i s p l a y - O b j e c t ) + r e f r e s h ( ) + r e c e i v e ( D i s p l a y O b j e c t ) + p a n e C o n t e n t ( C o n t e n t - I t e m S p e c i f i c a t i o n ) + d i s p l a y ( ) D i s p l a y O b j e c t C o n t e n t I t e m R e t r i e v a l A g e n t List S p e c i f i c a t i o n - i + r e t r i e v e ( C o n t e n t - I t e m S p e c i f i c a t i o n ) + r e c e i v e ( L o c a t i o n ) ContentItem + r e c e i v e ( D i s p l a y - L o c a t i o n O b j e c t ) - d e s t r o y ( ) « c o m p o n e n t » V i e w e r « p r o v i d e d i n t e r f a c e » + d i s p l a y ( L i s t ) Note that the operation signatures have been refined here. Compare to the previous sequence diagram t e m T y p e SE 430: Lecture 9

  32. Dealing with collections • Larman claims that it is not useful to explicitly show container/collection interfaces or classes in DCDs. • We disagree: we feel that collection/container classes should be shown if they convey valuable design decision information. Just use the «utility»stereotype to indicate their origin. • Example: • There are significant differences among the various types of collection classes. • If we were designing the internals of the Server, we might specify that stored objects will be held as key-value pairs in a Dictionary (HashMap in Java). • Making a conscious design decision to use a Dictionary rather than a Bag or a List should be captured in the DCD. SE 430: Lecture 9

  33. Associations • Unnamed (‘plain’) associations do not state exact relationships. • Simply indicate a symbolic relational (‘semantic’) dependency. • Plain associations are bi-directional—they indicate a relationship exists, but provide no more information. • Roles and naming define a direction on an association and refine its meaning. • Associations are usually later refined to stronger semantic relationships as more information is available: • Navigability,generalization,using, aggregation, or other named associations. • Cardinality: one-to-one, one-to-many, many-to-many, etc. SE 430: Lecture 9

  34. Association notation SE 430: Lecture 9

  35. Navigability and dependency • Navigability: • Asserts a direction to an association. • Implies assignment of responsibility for maintaining and providing knowledge in a relationship. • In Java, navigability corresponds to maintaining a reference. • Dependency relationships are less specific: they indicate a knowledge and necessary presence relationship between two model elements. • UML definition of dependency relationship: • “Dependencies are used to model dependencies among model elements where changes in the independent supplier elements may require changes to the dependent client elements.” [emphasis mine] SE 430: Lecture 9

  36. Navigability and dependency notation • Navigability: • Indicated by arrow with solid shaft and open arrowhead • Class at tail has the responsibility to ‘know’ (knowledge responsibility) about class at head • With unidirectional navigability, class at head does not know about class at tail • Dependency: • Indicated by arrow with dashed shaft and open arrowhead • May represent general (loosely-coupled) client/supplier relationships • One possible view of the relationships among the MID classes: SE 430: Lecture 9

  37. Dependency SE 430: Lecture 9

  38. Dependency SE 430: Lecture 9

  39. Iteration 3: Add MID associations, navigability, and dependencies P a n e « c o m p o n e n t » * V i e w e r d i s p l a y s c o n t a i n s D i s p l a y O b j e c t « p r o v i d e d i n t e r f a c e » - i t e m : C o n t e n t I t e m - 1 + d i s p l a y ( L i s t ) L o c a t i o n S p e c i f i c a t i o n * - c o n t e n t I t e m : 1 D i s p l a y O b j e c t - i t e m U R L 1 1 + r e f r e s h ( ) 1 + r e c e i v e ( D i s p l a y O b j e c t ) « c o m p o n e n t » u s e s D i r e c t o r y D o c u m e n t + p a n e C o n t e n t ( C o n t e n t - I t e m S p e c i f i c a t i o n ) 1 « p r o v i d e d i n t e r f a c e » 1 + d i s p l a y ( ) + w h e r e I s ( C o n t e n t - - p a n e L i s t : L i s t c o n t a i n s I t e m S p e c i f i c a t i o n , R e t r i e v a l A g e n t - p a n e L a y o u t C l i e n t R e f e r e n c e ) + c o n t e n t ( L i s t ) 1 « r e q u i r e d i n t e r f a c e » + r e t r i e v e ( C o n t e n t - * + r e c e i v e ( L o c a t i o n ) I t e m S p e c i f i c a t i o n , C l i e n t R e f e r e n c e ) N o t e a d d i t i o n « c o m p o n e n t » + r e c e i v e ( L o c a t i o n ) S e r v e r + r e c e i v e ( D i s p l a y - O b j e c t ) « p r o v i d e d i n t e r f a c e » - d e s t r o y ( ) * + r e q u e s t ( C o n t e n t - C o n t e n t I t e m * I t e m S p e c i f i c a t i o n , * u s e s S p e c i f i c a t i o n C l i e n t R e f e r e n c e ) « r e q u i r e d i n t e r f a c e » - i t e m T y p e + r e c e i v e ( D i s p l a y - O b j e c t ) o f C l i e n t R e f e r e n c e f o r u s e i n c a l l b a c k s . Note two-way navigability due to callback. SE 430: Lecture 9

  40. Generalization/specialization using inheritance • Sharing mechanism through which specializations acquire characteristics of more general constructs (superclasses). • Single inheritance: a specialization receives characteristics directly from a single more general construct. • Multiple inheritance: a specialization receives characteristics from multiple more general constructs. • Avoid the complexity of multiple inheritance: try to use interfaces or composition instead. SE 430: Lecture 9

  41. Notation SE 430: Lecture 9

  42. Generalization – type consistency • The specialized subclass should still behave like its superclass in the general sense: the subclass should conform (method signatures and method behavior) to the superclass’ interface. • Specialized class usually augments behavior of superclass in a limited fashion, rather than radically changing the behavior defined in superclass. • Principle of substitutability: you should be able to substitute the subclass for the superclass transparently. (see note) SE 430: Lecture 9

  43. An alternative to inheritance: interfaces and implements • Some O-O languages such as Java allow only single inheritance • How do you combine diverse characteristics into a single class? • Use interfaces – a means to add specialized behavioral characteristics to a class • Allows fine-grained tuning of class capabilities without the overhead of inheritance • Classes can implement multiple interfaces • Requires implementor to provide implementations for every method in implemented interfaces SE 430: Lecture 9

  44. Aggregation and composition • There exists a whole/part relationship between two objectsif and only if an aggregation/composition relationship exists between their corresponding classes. • Aggregation (‘has-a’ or containment by reference): • Contained object is part of container, but can exist independently. • Ownership of contained object is a policy decision. • Contained object may be part of other aggregations. • Example: In Java, create an object and place it in a container, but maintain an external reference to object: ArrayList aList = new ArrayList(); Integer anInt = new Integer(42); aList.add( anInt ); SE 430: Lecture 9

  45. Aggregation and composition • Composition (‘contains-a’ or containment by value): • Contained object does not exist independently of its container. • Contained object is owned by container. • Contained object may be part of only one composition (only one owner). • Example: In Java, create an anonymous instance and directly place it in a container, with no external reference to the object: ArrayList aList = new ArrayList(); aList.add( new Integer(42) ); SE 430: Lecture 9

  46. Notation SE 430: Lecture 9

  47. Composition SE 430: Lecture 9

  48. Another alternative to multiple inheritance: delegation or composite class • Delegating class interface (composite class) publicly exhibits only needed methods, not the whole set of methods from all composite components. • Hides composite components within its encapsulation. • Adds only attributes specific to composite class. • Privately extends semantics of superclass by adding behavior to coordinate interaction of composite components. • Useful if: • Interfaces are not available in the implementation language. • Composite object needs most of the functionality of the components. play() { audio.play(); video.play(); } SE 430: Lecture 9

  49. Iteration 4: Add DocumentAssembly generalization and aggregation relationships Note: Location left out due to space limitations. SE 430: Lecture 9

  50. Notes: interfaces and patterns Runnable run() RetrievalAgent Note the use of Interface to show patterns, etc. Here is the implementation of threading: Use a similar construction for Observer, Proxy, Dispatcher patterns SE 430: Lecture 9

More Related