IT3101 Object Oriented Systems Development

1
IT3101Object Oriented Systems Development

2
IT3101- Object Oriented Systems Development

• Web site www.ict.cmb.ac.lk/bit.htm
• Teaching Materials
• Whats New / Teaching Material / Object
  Oriented Systems Development
• Email Address to contact
• OOSD_at_ict.cmb.ac.lk

3
IT3101- Object Oriented Systems Development

• Rational Rose Student Version
• Link
• Whats New / Student Edition

4
Frequently Asked Questions

• Do we need to memorize the Rational Rose
  Commands?
• No. You need to understand the fundamentals of a
  CASE tool and UML.

5
Frequently Asked Questions cont

• Is it ok to use Rational Rose 4/98 ?
• Yes.
• Note Activity diagrams are not supported.

6
Frequently Asked Questions cont

• Could you please let us know the examination
  procedure for the module IT 3101?
• Examination Paper will consist of two parts.
• Part 1 1 ½ Hour paper consisting of Multiple
  Choice Questions
• Part 2 1 ½ Hour Paper consisting of Structured
  Questions

7
Examination Procedure cont..

• Students will be given two assignments during the
  semester.
• There will be multiple choice or structured
  questions based on these assignments.

8

• Give an example of a structured question?
• Identify the possible Classes from the given
  problem domain.
• Out of the five books recommended which is the
  best?
• Visual Modeling with Rational Rose 2000
• UML User Guide

9
IT3101-Object Oriented Systems Development

• Chapter 2
• Visual Modeling using Unified Modeling Language
  (UML)

10
What is Visual Modeling

• It is a way of thinking about problems using
  models organized around real-world ideas.

Useful for understanding problems, communicating
with every one involved with project, modeling
enterprises, preparing documentation, designing
programs and databases.
11
Visual Modeling

• Helps organize, visualize, and understand
  complexity.
• Is the mapping of real processes of a system to a
  graphical representation.
• Is an abstraction that portrays the essentials of
  a system, making the problem easier to
  understand.
• Is a proven and accepted engineering technique.
• Has a common vocabulary, the UML.

12
Components needed for a successful project

• You can learn a notation, but if you dont know
  how to use it (process), youll probably fail.

Notation
Tool
Process
Triangle for Success
13
Components needed for a successful project cont..

• You may have a great process, but if you cannot
  communicate the process (notation), you will
  probably fail.

Notation
Tool
Process
Triangle for Success
14
Components needed for a successful project cont

• Lastly, if you cannot document the artefacts of
  your work (tool), you will probably fail.

Notation
Tool
Process
Triangle for Success
15
The Role of Notation

• Notation plays an important part in any model.
• It is the glue that holds the process together.

16
Notation has three (3) roles.

• It serves as the language for communicating
  decisions that are not obvious or cannot be
  inferred from the code itself

17
Notation has three (3) roles

• It provides semantics that are rich enough to
  capture all important strategic and tactical
  decisions.

18
Notation has three (3) roles

• It offers a form concrete enough for humans to
  reason and tools to manipulate.

19
Modeling Language

• Most important part of a methodology
• It is the key part for communication.

Any natural language has Words, Sentences, and
Grammar Modeling language also has Symbols,
Diagrams, and Connection Rules
20
Unified Modeling Language

• It most directly unifies the methods of Booch,
• Rumbaugh (OMT),
• and Jacobson
• as well as the best ideas from a number of
  other methodologies.

21
UML Inputs
Jacobson
Booch
Rumbaugh (OMT)
Mayer Pre and post conditions
Odell classification
UML
Harel State charts
Shlaer-Mellor Object life cycles
Wirfs-Brook Responsibilities
Gamma et al Frameworks, Patterns, notes
Fusion Operation descriptions Message numbering
Embly Singleton classes
22
UML cont..

• The UML is an attempt to standardize the
  artifacts of analysis and design
• ie. Semantic models,
• Syntactic notations,
• and diagrams

23
Rational Unified Process

• Components needed for a successful project
• If you dont know how to use the notation
  (process), youll probably fail.
• Rational Unified Process is the process you will
  be learning for this module.

24
The Rational Rose Tool

• Any software development method is best supported
  by a tool.
• if you cannot document the artefacts of your work
  (tool), you will probably fail.
• The tool you will be using for this module is
  Rational Rose

25
Use Case Diagrams

• Actors
• Represents anyone or any thing
• that must interact with the system
• An Actor may
• Only input information to the system.
• Only receive information from the system.
• Input and receive information to and from the
  system.
• Typically they are found in the problem
  statement and by conversations with customers and
  domain experts.

26
Use Cases

• What is a Use Case?
• It is a typical interaction between a user and a
  computer system.
• They are the primary elements in software
  development.
• They represent the functionality provided by the
  system. ie what capabilities will be provided to
  an actor by the system.

27
Use Cases cont..

• The collection of Use Cases for a system
  constitute all the defined ways the system may be
  used.
• How to capture Use Cases?
• By talking to typical users and discussing
  things that they might want to do with the
  system.
• eg. Borrowing of books , Returning of books
  etc. (Library System)

28
Documenting Use Cases

• A flow of events document is created for each use
  case
• Written from an actor point of view
• The flow of events for a use case is a
  description of the events needed to accomplish
  the required behavior of the use case.

29
Documenting Use Cases

• Flow of events Typical contents
• When and how the use case starts and ends
• What interaction the use case has with the actors
• What data is needed by the use case
• The normal sequence of events for the use case.
• The description of any alternate or exceptional
  flows.

30
Documenting Use Cases
Flow if events - commonly use template. X Flow of
events for the ltnamegt Use Case X.1
Preconditions X.2 Main Flow X.3 Sub Flows
(if applicable) X.4 Alternate Flows Where X is
a number from 1 to the number of use cases
31
Use Case Diagram

• Introduced by Jacobson (1994) to visualize use
  cases.

ltltExtendsgtgt
ltltCommunicatesgtgt
ltltincludegtgt
Actor
ltltincludegtgt
ltltincludegtgt - Drawn to show functionality that
is shared by several Use Cases ltltExtendsgtgt -
Shows optional behavior of a Use Case
32
Use Case Diagram con..
ltltincludegtgt
Open Document
Get File Name
ltltincludegtgt
User
Save Document
ltltextendsgtgt
First Save
User Saving a word processor document
Create Document
33
Use Case Diagram con..
Server
Reply
Send
User
Forward
ltltincludegtgt
Generalization
User sending an E-mail message
Edit
34
Structured Questions

• (1)   Following is a use case example for an
  Order Processing Application.

Request Catalogue
Place Order
Arrange Payment
Order Clerk
Order Product
Arrange Credit
Pay Cash
35

• Write down the types of relationships for the
  following .
• Order Clerk and Place Order
• Place Order and Order Product
• Place Order and Request Catalogue
• Place Order and Arrange Payment
• Arrange Payment and Pay Cash
• Arrange Payment and Arrange Credit

36
ltltextendsgtgt
Request Catalogue
Place Order
ltltCommunicategtgt
ltltIncludegtgt
ltltIncludegtgt
Arrange Payment
Generalization
Order Product
Order Clerk
Generalization
Arrange Credit
Pay Cash
37
Class Diagrams.

• They are backbone of nearly all OO Methods.
• A class diagram describes the types of objects in
  the system and the various kinds of static
  relationships that exist among them.
• It also shows the attributes and services of a
  class and the constraints that apply to the way
  objects are connected.

Book
Accno
Title
UML Notation for a Class
GetAuthor(int)
38
Stereotypes and Classes

• Stereotypes allows the analysts to partition the
  system.
• Entity, Boundary, Control
• Entity They are needed to perform task internal
  to the system. Reflect a real world entity.
• Boundary They provide the interface to a user
  or another system. (ie. Interface to an actor).
  Handles communication between system surroundings
  and the inside of the system.

39
Stereotypes and Classes con..

• Control Sequencing behaviour specific to one or
  more use cases. Co-ordinates the events needed to
  realise the behaviour specified in the use case.
• Eg. Running or executing the use case.

40
Packages

• If a system contained only a few classes, you
  could manage them easily.
• Most systems are composed of many classes.
• Packages are used to group them together for ease
  of use, maintainability, and reusability.

41
Packages

• By grouping classes to packages we can look at
  the higher level view of the model.
• Package diagrams help you to maintain control
  over a systems overall structure.

People Information
UML Notation
42
Specifying Relationships

• Association Relationships
• Aggregation Stronger form of Association
• Generalization
• Dependency Relationship
• Weaker form of relationship

1
0..
Customer
Orders
Aircraft
Engine
Glider
Aircraft
Client
Supplier
43
Specifying Relationships cont..

• Association or Aggregation?
• Often domain dependent.
• What type of relationship should be used to model
  a car with its tires?
• If the application is a service center - its
  aggregation
• If the application is a tire store, you will
  care about the tire independent of a car - its
  association