CSC 395

1
CSC 395 Software Engineering

• Lecture 13
• Object-Oriented Analysis or
• Let the Pain Begin (At Least Im Honest!)

2
Todays Goal

• Begin discussion OO analysis
• How do we transition from requirements to code?
• What can we do to help create reusable designs?
• Ways to check our analysis
• How UML helps express these ideas

3
Analysis Workflow

• Translate project to software engineering terms
• Begins with use-cases and textual descriptions
• End with a highest-level modules (classes), what
  each modules must do, and how they may interact
• Workflow accomplishes this in two ways
• Obtain deeper understanding of the requirements
• Describe requirements in manner resulting in
  maintainable design implementation
• For unified process, this is use case driven
• Everything begins with the use cases

4
3 Types of Classes

• Unified Process concept to simplify designs
• Entity classes hold the long-lived data
• Boundary classes performs the input output
• Control classes do complex processing and actions
• Types exist only for purposes of design
• Need UML stereotypes to display them

5
Iteratively Extract Classes

• Functional modeling
• Present scenarios of use cases
• Class modeling
• Find entity classes and their attributes
• Determine their interrelationships and
  interactions
• Show this information using UML class diagrams
• Dynamic modeling
• Determine operations for entity class
• Display information using UML statechart

6
Scenarios

• Use case provides generic description of
  functionality
• Scenario scripts one instance of the use case
• Provides idea of how use case could play out
• Study more than one scenario per use case
• Need comprehensive insight into target product
• Examining multiple situations reduces chance that
  rare condition is overlooked
• Details skipped here cause impossible-to-find
  errors later

7
Normal Scenario Elevators
8
Exception Scenario Elevators
9
Entity Class Modeling

• Extract classes and their attributes
• Represent them using a UML class diagram
• Diagram enables deducing class properties
• Enables early refinement of class design
• Try deducing from use cases and scenarios
• Risks finding too many candidate classes
• Instead use domain knowledge via CRC cards or
  play English major and use noun extraction
• But remember, these find candidate classes

10
Noun Extraction

• Initially finds entity class candidates
• Not all entity classes will be found during
  initial pass
• Some classes in early passes will not be used
• Also provides really good hints as to other
  classes
• Identify nouns in requirements
• Eliminate classes external to the problem
• Ignore abstract (non-physical) nouns and those
  for communication

11
Boundary Classes

• Perform systems inputs outputs
• Inputs and outputs are often complex
• Each input output combine many details
• Each detail may need own boundary class
• Go from simplest classes to complex class
• Combining simple classes is easy
• Breaking up complex classes is much harder
• Boundary classes may duplicate primitive type,
  could skip defining these classes
• Instead hard-code primitive everywhere
• Change by finding and replacing all related code

12
Control Classes

• Defined for non-obvious algorithms using multiple
  items
• Rule of thumb algorithm is non-obvious if it
  does not have a name
• Includes all plural nouns in requirements
• If exact number known, use an array
• Otherwise need Collection class

13
Elevator Controller

• Buttons in elevators and on the floors control
  the movement of n elevators in a building with m
  floors. Buttons illuminate when pressed to
  request the elevator stop at a specific floor
  the illumination is canceled when the request has
  been satisfied. When an elevator has no
  requests, it remains at its current floor with
  its doors closed.
• Entity Class Boundary Class Control Class
• External Classes (ignored)

14
UML Class Diagrams

• Classes drawn as a 3-part box
• Class name written in top portion of box
• Attributes (fields) written in middle portion of
  box
• Operations (methods) written in bottom portion

15
Connection Between Classes

• Relationships shown via connecting lines
• Line its marks denotes type of relationship
• Multiplicity numbers in relationship labeled
• Advanced multiplicity relationships possible
• used when relationship involves 0 or more
• used when relationship involves 1 or more
• 1..4 when relationship may need 1 to 4
  instances

16
Connection Between Classes

• Examples of relationships
• Aggregation
• Car aggregates Chassis, Engine, Wheel
• Composition
• Chessboard is composition of Squares
• Association
• Object calls methods in other object, but does
  not contain fields
• Generalization (inheritance)

17
UML Class Diagram for Elevator Controller

• Button objects currently serves two purposes
• Buttons in elevator directing travel to a floor
• Buttons on a floor requesting travel
• Solution Make 2 specializations of Button

18
UML Class Diagram for Elevator Controller

• n to m communication is bad
• This is hard to impossible to code
• Add classes to simplify this process

19
UML Class Diagram for Elevator Controller
20
CRC Card

• Good for use with explicit knowledge domain
• Excellent for testing class design
• Create card for each class
• List Class, Responsibilities, Collaborations
• Responsibilities list actions class performs
• Collaboration lists associated classes
• Responsibilities should either be
• Change state of the current class
• Send message (e.g., call method) of class whose
  state changes

21
CRC Card Example
22
Dynamic Modeling

• Dynamic modeling is 3rd step in extraction
• Constructs statechart showing software operation
• Operations determined from the scenarios
• State diagrams (aka, event flow) rely on
  meaningful symbols
• Solid circle represents initial state
• White circle containing small black circle is
  final state
• Other states use rectangles with rounded corners
• Arrows represent possible state transitions

23
Dynamic Model Example
24
For Next Lecture

• Complete discussion OO analysis
• Developing sequence collaboration diagrams to
  refine use cases
• Give you chance to practice all these ideas