Lecture%201%20OOMPA

1
Lecture 1 OOMPA

• Course formalities
• Object oriented analysis and design
• Object oriented concepts
• Encapsulation
• Inheritance
• Polymorphism
• Abstract classes
• Associations

2
2D1359 2D1360 Object Oriented Modeling,
Programming Analysis
Lecturer Frank Hoffmann hoffmann_at_nada.kth.se
(kursledare) Bjoern Eiderbaeck bjorne_at_nada.kth.se
Assistents Ronni Johansson rjo_at_nada.kth.se Caro
lin Jonsson d98-cjo_at_nada.kth.se Jonas Sjoebergh
jsh_at_nada.kth.se Marcus Weiland d99-mwe_at_nada.kth.se
Course webpage http//www.nada.kth.se/kurser/kt
h/2D1359
3
Seminars Labs

• group 1 Frank Hoffmann (in English)
• group 2 Ronni Johansson
• group 3 Jonas Sjoebergh
• group 4 Carolin Jonsson
• group 5 (OOMPAE) Marcus Weiland
• Extra seminar for OOMPAE on Wednesday 5/9 1000
• Introduction to JAVA
• First seminar groups 1-4 rooms D31-34 Wed.
  12/9 1500
• group 5 (OOMPAE) room V23 Wed. 12/9 1000
• Extra lab OOMPAE only Wed. 5/9 1300 (red)
• First labs Fri. 14/9 800-1000 and
  1000-1200

4
Course Literature

• OO Modeling and Design
• Applying UML and Patterns An Introduction to
• Object-Oriented Analysis and Design and the
  Unified Process
• Craig Larman, 2/e, Prentice-Hall
• JAVA
• Thinking in JAVA
• Bruce Eckel, 2/e, Prentice-Hall, available
  online at
• www.bruceeckel.com
• Other useful books
• Design Patterns, Erich Gamma et al,
  Addison-Wesley
• UML Distilled, Martin Fowler, Addison-Wesley

5
Course Registration / Accounts

• Obtaining a UNIX account at NADA
• sign up on the list with first and last name
• visit DELPHI to create your account
• http//www.sgr.nada.kth.se/delfi
• Register for the course with RES
• UNIX command res checkin oompa01
• or for OOMPA res checkin oompae01

6
Course Requirements

• Lectures
• The course contains 20 lectures in period 1 and
  2
• Seminars
• 6 seminars that cover the Larman book
• Each seminar consists of two parts (delmoment)
• 9 out of 12 parts (delmomenter) have to be
  completed and passed
• Participation in the seminars requires to read
  the assigned text and to be able to present
  selected chapters during the seminar
• Exam
• Week 43 exact date to be announced

7
Course Requirements

• Labs
• 5 mandatory labs
• labs are programmed and examined in groups of two
• Labs must be completed and presented by the
  dead-line, otherwise you receive fewer points for
  the grade (betyg)
• Lab1 Figurer i hierarki due 28/9/01
• Lab2 Design patterns due 12/10/01
• Lab3 Bank due 23/11/01
• Lab4 C due 7/12/01
• Lab5 VisualWorks due 14/12/01
• Extra labs to improve grade (betyg)

8
Grading

• To pass the course you have to pass the exam (1
  point), the labs (3 points) and the seminars (2
  points)
• Computation of grades
• Seminar series worth 3 units.
• Labs worth 3 units (0.5 units less per deadline
  missed)
• Exam worth 3-5 units (same as grade)
• Total number of points 9-11, divided by 3,
  results in grade 3 to 3 2/3, which is rounded to
  final grade 3 to 4.
• To improve your grade you can complete extralabs
  worth 1-3 units.

9
Example Grading

• Example grade calculation
• Exam 4 points
• Labs 3 points
• Seminar series 3 points
• Total 10 points / 3 3 1/3 betyg 3
• To improve to grade (betyg) 4, you can do an
  extralab worth 1 point, to improve to grade
  (betyg) you need two extra labs worth at least 4
  points

10
Course Objectives

• Knowledge about the principles and concepts
  behind the object oriented programming paradigm.
• Knowledge and skills in using methods for the
  development of object oriented programs, i.e.
  analysis, design, modeling, implementation,
  testing.
• Experience of object oriented programming in
  JAVA, Smalltalk and C.

11
Course Prerequisites

• 2D1340 or 2D1343 Introduction to Computer Science
• 2D1351 Programming style or 2D1344 Fundamentals
  of CS
• Knowledge and experience in an object oriented
  programming language JAVA or C
• This course will NOT teach you how to write JAVA
  programs!
• Students should be familiar with object oriented
  concepts such as objects, classes, encapsulation,
  interface, inheritance and polymorphism.

12
Course Contents

• Object oriented analysis and design
• Unified modeling language (UML)
• Design Patterns (GoF, GRASP)
• Requirement specifications
• Extreme programming XP
• System and object design
• Other OO languages C and Smalltalk

13
Course Contents

• Mastering object oriented analysis and design
  (OOA/D) is critical to create robust and
  maintainable object systems.
• UML has emerged as the standard notation for
  modeling. We teach the skills of OOA/D using the
  UML notation. UML in itself is not a methodology.

14
Course Contents

• Design patterns represent the best practice
  idioms and solutions that OO design experts apply
  in order to create OO systems. You will learn to
  understand and to apply design patterns including
  the popular Gang-of-Four (GoF) and GRASP patterns
  which communicate fundamental principles in OO
  design.

15
Object Oriented Analysis Design

• OOA/D includes many possible activities and
  artefacts. The single most crucial skill is
• A critical, fundamental ability in OOA/D is to
  skillfully assign responsibilities to software
  components. (Larman 2001)
• General responsibility assignment to software
  processes (GRASP)
• GRASP patterns describe fundamental principles
  in object design and responsibility assignment.

16
OO Analysis Design

• Analysis emphasizes an investigation of the
  problem and requirements, rather than a solution.
  How will be a new library information system be
  used.
• Analysis encompasses requirement analysis (an
  investigation of the requirements) and/or object
  analysis (an investigation of the domain objects)

17
OO Analysis Design

• Design emphasizes a conceptual solution that
  fulfills the requirements, rather than its
  implementation. For example, a description of a
  database schema and software objects.
• The term design is best qualified as in object
  design or database design.
• Analysis and design can be summarized as
• Do the right thing (analysis), what needs to be
  done
• Do the thing right (design), how is it done.

18
OO Analysis Design

• During object-oriented analysis, there is an
  emphasis on finding and describing the objects
  or concepts- in the problem domain. For example
  in case of the library system, some of the
  concepts include Book, Library, Patron.
• During object-oriented design, there is an
  emphasis on defining software objects and how
  they collaborate to fulfill the requirements. For
  example in the library system, a Book software
  object may have a title attribute and a
  getChapter method.

19
OO Analysis Design
visualization of domain concept
domain concept
Book title getChapter()
public class Book private String title
public Chapter getChapter(int)
representation in an object-oriented programming
language
20
OOA/D in a Nutshell

• Example Dice Game
• A player rolls two die. If the total is seven,
  they win, otherwise they loose.

21
OOA/D in a Nutshell

• Define use cases
• Define domain model
• Define interaction diagrams
• Define and design class diagrams

22
Define Use Cases

• Requirement analysis (what needs to be done)
  includes a description of related domain
  processes, these can be written as use cases.
• Use cases are written stories ( possibly
  diagrams).
• Play a dice game use case
• Play a dice game A player picks up and rolls the
  dice. If the dice face value total seven, they
  win, otherwise, they loose.

Play a dice game
Player
23
Define a Domain Model

• OO analysis is concerned with creating a
  description of the domain from the perspective of
  classification of objects.
• A decomposition of the domain involves an
  identification of the concepts, attributes and
  associations that are considered relevant.
• The result can be expressed in a domain model,
  which is illustrated in a set of diagrams that
  show domain concepts and objects.

24
Define a Domain Model
1 Rolls 2
Die faceValue
Player name
1
2
Plays
concept
attribute
1
1
Includes
DiceGame
association
25
Define Interaction Diagram

• Object oriented design is concerned with defining
  software objects and their collaborations. A
  common notation to illustrate these
  collaborations is the interaction diagram. It
  shows the flow of messages between software
  objects and thus the invocation of methods.

26
Define Interaction Diagram

• The interaction diagram illustrates the essential
  steps of playing, by sending messages to the
  instances of the DiceGame and Die classes.

DiceGame
die 1 Die
die2 Die
play()
roll()
fv1getFaceValue()
roll()
fv2getFaceValue()
27
Define Design Class Diagrams

• Interaction diagrams render a dynamic view of
  collaborating objects.
• Design class diagrams provide a static view of
  the class definitions as they illustrate the
  attributes and methods of the classes.
• For example, in the dice game, an inspection of
  the interaction diagram leads to the partial
  design class diagram. Since a play message is
  send to a DiceGame object, the DiceGame class
  requires a play method, while class Die requires
  a roll and getFaceValue method.

28
Define Design Class Diagrams

• In contrast to the domain model, the design class
  diagram shows software classes, rather than
  illustrating real-world concepts.

DiceGame die1 Die die2 Die play()
Die faceValue int roll() getFaceValue() int
2
1