2014-2015

Lecture 5

C# Language Fundamentals

OOP Concepts

Phil Smith

Learning Outcomes LO1 LO1 Understand the principles of object oriented programming

1.1 discuss the principles, characteristics and features of

objected oriented programming.

2.1 identify the objects and data and file structures required

to implement a given design.

2.2 design an object orientated programming solution to a

given problem.

OOP Principles by example Now Aggregation, Composite classes and Association. We have already seen weak and strong association with

properties and get/set etc

Now we need to consider object ownership and relationships Composition is an Association Aggregation is an Association

Composition is a strong Association (If the life of contained

object totally depends on the container object, it is called strong association)

Aggregation is a weak Association (If the life of contained object doesn't depends on the container object, it is called weak association)

OOP Principles by example

Task

Follow my lead on Aggregation, Composite classes and Association.

Overview of UML Diagrams

Structural : element of spec. irrespective of time

Class

Component

Deployment

Object

Composite structure

Package

Behavioral : behavioral features of a system / business process

Activity

State machine

Use case

Interaction

Interaction : emphasize object interaction

• Communication(collaberation)

• Sequence

• Interaction overview

• Timing

UML A class is shown as a rectangular box with three

compartments

Class diagrams are static – they display what interacts but not what happens when they do interact.

Name is shown in bold and should be a noun

Fields describe the class. They should have meaningful names and define the type

Methods are actions used to manipulate the attributes or perform a specific task

Verbs in the specification

Class Diagrams

Class Name

Methods

Fields (or properties)

UML representation VS representation

Class Diagrams Read the scenario provided, or in the case of a real

project, read the specification

Sort out all the nouns

These become the classes

Sort out all the verbs

These become the methods

Inheritance

Use Case A use case

describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse

An actor is a person, organization, or external system that plays a role in one or more interactions with your system

Associations between actors and use cases are indicated in use case diagrams by solid lines

UML The following are some common models used in UML:

Software requirement specification (SRS): A textual description of the overall responsibilities and scope of the system.

Use case: A textual/graphical description of how the system will behave from the users’ perspective. Users can be humans or other systems.

Class diagram: A visual blueprint of the objects that will be used to construct the system.

Sequence diagram: A model of the sequence of object interaction as the program executes. Emphasis is placed on the order of the interactions and how they proceed over time.

Collaboration diagram: A view of how objects are organized to work together as the program executes. Emphasis is placed on the communications that occur between the objects.

Developing an SRS The purpose of the SRS is to do the following:

Define the functional requirements of the system

Identify the boundaries of the system

Identify the users of the system

Describe the interactions between the system and the external users

Establish a common language between the client and the program team for describing the system

Provide the basis for modelling use cases

Introducing Use Cases Use cases describe how external entities will use the

system. These external entities can be either humans or other systems and are referred to as actors in UML terminology. The description emphasizes the users’ view of the system and the interaction between the users and the system.

Use cases help to further define system scope and boundaries. They are usually in the form of a diagram

Generic Use Case

What do you think the use case for View Club Info would look like?

View Club Info

Another Example Description: The user adds a team to the club. The user can then view the teams for the club. • Preconditions: The user has checked the club can be added. • Postconditions: The user can confirm the new team by viewing all teams for the club.

Use cases diagram

Use cases diagram

Use cases diagram

Extensions Another way that use cases relate to each other is

through extension.

You might have a general use case that is the base for other use cases.

The base use case is extended by other use cases.

Extension

Summary We have learnt about –

Designing objects with classes.

We have learnt how to implement some OOP principles and features using C#.

We have also learnt basic UML for Use case and class diagrams.

Assignment 1

Now you can do Assignment 1.