Software Engineering I
Oct. 14, 2012 Notes

Last time we reviewed the basics of OCL and completed review of class diagrams

This time we will investigate Design and Design Patterns

Design is transforming requirements into an outline of the software structure.

Involves two basic parts

  Architectural design - a high-level system overview
    -Includes components and external relationships

  Detailed design - component level design with much more detail than architecture 
    design
    -Maps functional requirements to design components

We have been looking at tools for detailed design
  -UML
  -OCL
  -Use cases

This also includes
  -Functional Decomposition - breaking the design into modules containing different
   functionality

  -Relational database design
    -Data modeling (ER diagrams)
    -Logical DB design
    -Physical db design

  -Object-oriented design and UML
    -Class diagrams
    -Use cases
    -Other UML such as State, Activity, Communication, and Sequence diagrams

Often, detailed designs and architectural designs are repeated.

Some detailed design patterns include

  Abstraction-Occurence
  Observer
  Player role
  Delegation
  Adapter
  Facade
  Proxy
  Immutable
  Read-only interface
  Factory
  
Design patterns are commonly used class diagram types in SW engineering
  -They are reusable solutions to common problems

Often patterns include the following description
  - Name
  - Context - when it applies
  - Problem 
  - Issues or related patterns
  - Solution
  - Patterns that cannot be used in place of this one

Abstraction-Occurrence
  - Often used when forming system domain model class diagrams
  - Objects in the domain model are called occurences
  - They might share common information but differ in some way

  Example: Episodes of a TV series

  They have the same title but have a different storyline

  Problem - how to best represent occurrences in the class diagram

  Ideally we would like to represent members without duplicating information

  Solution - Include an abstraction class that holds data common to occurrences

  +-----------------+ 1         * +----------------+
  | <<Abstraction>> |-------------| <<Occurrence>> |
  +-----------------+             +----------------+ 

  +-----------------+ 1         * +----------------+
  |  TVSeries       |-------------|     Episode    |
  +-----------------+             +----------------+ 
  | seriesName      |             |  number        |
  | producer        |             |  title         |
  +-----------------+             |  storySummary  |
                                  +----------------+

  Single classes likely won't work in place of an abstraction occurrence

  Related to the "Title-Item" pattern developed by Erikson and Penker

General Hierarchy Pattern

  - Used when finding a natural hierarchy
  - Ex: Manager to employee in organization chart
        Directories and subdirectories

  - We have zero or more subordinate objects to a controlling object

  - Drawing this hierarchy is an interesting problem
  - We want to remain flexible yet prevent some objects from controlling others
 
  - Solution - include an abstract <<Node>> class with common features
             - include two child classes of the abstract Node
               + One <<SuperiorNode>>
               + One <<SubordinateNode>>
             - include an association called <<subordinates>> from the 
               <<SuperiorNode>> to the <<Node>>

  +----------+  *   <<subordinates>>
  | <<Node>> |-------------------+
  +----------+                   |
        ^                        |
       / \                       |
       ---                       |
        |                        |
   +-------------------------+   |
   |                         |   |
  +-------------------+   +----------------+
  |<<SubordinateNode>>|   |<<SuperiorNode>>|
  +-------------------+   +----------------+

  Using a regular inheritance hierarchy will not work in place of this.

Player-Role Pattern
  - When drawing many types of class diagrams we often see roles
  - Role - set of features associated with an object in a particular context
  - Objects may play different roles in different contexts

  Ex: Students may be either full-time or part-time
                             graduate or undergraduate

  - How can we best model players with multiple roles, which may change

  - Solution - use associated <<Player>> and <<Role>> classes where <<Role>> is
    an abstract superclass

  +----------+               +----------------+
  |<<Player>>|---------------|<<AbstractRole>>|
  +----------+               +----------------+
                                     ^
                                    / \
                                    ---
                                     |
                        +------------------------+
                        |                        |
                  +-----------+        +-----------+
                  | <<Role1>> |        | <<Role2>> |
                  +-----------+        +-----------+

  +---------+               +-----------------+
  | Student |---------------| EnrollmentStatus|
  +---------+               +-----------------+
       ^                                ^
      / \                              / \
      ---                              ---
       |                                |
  +------------------------+         +-----------------+
  |                        |         |                 |
 +---------------+ +----------+   +----------+    +----------+
 | Undergraduate | | Graduate |   | FullTime |    | PartTime |
 +---------------+ +----------+   +----------+    +----------+