AOOP

• Model


  An abstraction describing a subset of a system
• View

  Depicts selected aspects of a model
• Notation


  A set of graphical or textual rules for depicting views
• Views and models of a single system may overlap each other
• System


  • Aircraft
• Models


  • Flight simulator
  • Scale model
• Views


  • Blueprints
  • Electrical wiring
  • Fuel system
• UML is a multi-diagrammatic language
• UML diagram


  A view into a UML model

  
• Diagram presented from the aspect of a particular stakeholder
• A UML diagram provides a partial representation of the system

  
• UML diagrams are semantically consistent with other views

  
• Views


  Partial representations of a system that fit the context
• Not all systems require all UML views
• A system might need additional views beyond the standard UML views
• You can model 80% of most problems by using about 20% of UML
• Basic Modeling Steps


  1. Use Cases to capture requirements

  2. Domain Model to capture process and key classes

  3. Design Model to capture details and behaviors of use cases and domain objects, and add classes that do the work and define the architecture
• UML Baseline


  • Use Case Diagrams
  • Class Diagrams
  • Package Diagrams
  • Interaction Diagrams (Sequence, Collaboration)
  • Activity Diagrams
  • State Transition Diagrams
  • Deployment Diagrams

  
• Use Case Diagram


  Used during requirements elicitation to represent external behavior

  
• Actor


  Represents a role, a type of user of the system
• Use Case


  Represents a sequence of interaction for a type of functionality; a summary of scenarios
• Use Case Model


  The set of all use cases, a complete description of the functionality of the system and its environment
• Actors


  • Passenger
  • GPS satellite
• Use Case


  • Unique name
  • Participating actors
  • Entry conditions
  • Flow of events
  • Exit conditions
  • Special requirements
• <<extends>> relationship


  Represents exceptional or seldom invoked cases, where the exceptional event flows are factored out of the main event flow
• <<includes>> relationship


  Represents behavior that is factored out of the use case for reuse, not because it is an exception
• Use Cases


  Useful for determining requirements, communicating with clients, and generating test cases
• All use cases need to be described for the use case model to be useful
• Class Diagram


  Gives an overview of a system by showing its classes and the relationships among them
• Class Diagram Perspectives


  Conceptual (software independent, language independent), Specification (focus on interfaces), Implementation (focus on implementation)

  
• Class


  Represents a concept, encapsulating state (attributes) and behavior (operations)
• Instance


  Represents a phenomenon, with a name that can contain the class of the instance and attribute values
• UML Class Notation


  A class is a rectangle divided into three parts: name, attributes, operations. Modifiers can be used to indicate private, public, protected, static.
• Association


  A relationship between instances of two classes, where one class must know about the other to do its work
• Aggregation


  An association where one class belongs to a collection
• Composition


  A strong form of Aggregation where the components cannot exist without the aggregate
• Inheritance


  A superclass-subclass relationship, indicated by a triangle pointing to the superclass
• UML Multiplicities


  Specify details about the cardinality of associations
• Static design describes code structure and object relations, while dynamic design shows communication between objects
• Object Diagram


  Shows instances of Class Diagrams and links among them, a snapshot of the objects in a system