MIS541AUniversity of Arizona Lecture 13 Object-Oriented Analysis -II.

MIS541A University of Arizona

Lecture 13Object-Oriented Analysis -II


Topics

Key ideas behind OO……… Use–cases..


Key ideas behind the Object Model..

•Abstraction…..

•Encapsulation

•Modularity

•Hierarchy

•Typing

•Concurrency

•Persistence

ALL OO MODELS MUST REFLECT THESE CHARACTERISTICS…


Focus on essential properties of the “real world” for the system…..Dependent on observer..Pick and choose..Objects capture those properties..Entity abstractions..Actions…etc…..

ABSTRACTION


How an object is implemented is irrelevant ..Users of the object only need to know what it does..and how it can be used..(not its internals..)..Reuse……..

ENCAPSULATION……..


Encapsulation/HidingThe object encapsulatesboth data and the logicalprocedures required tomanipulate the data

Achieves “information hiding”

method # 1

data

method # 2

method # 4

method # 5

method # 6

Access internals only via

Methods……..

Controlled access


A collection of objects with some common theme or purpose…Easy for maintenance and use..Partitions into physical groups…

MODULARITY


Helps in ordering and managing abstractions…….

Single & Multiple inheritance..

Is-a versus part-of..

HIERARCHY……..


Type enforces physical rules…..of combining objects..substitution etc..

TYPING


Multiple processes running at the same time ..I.e. multiple objects are active at the same time..things happen in parallel……(unless they need to access a common resource!)

CONCURRENCY


Objects live through time……..and space…PERSISTENCE


OO Analysis

The process of defining the classes and interactions……

Usually done using what is called UML – The Unified Modeling Language… provides a series of diagrams…

OO Analysis can be quite complex – tends to combine both programmers/domain analyst perspective…

We will focus on data modeling, process modeling and state modeling……..


Advantages & Disadvantages of OOP

Facilitates reuseAllows for building complex systemsPerfomance issues - speed, memoryManaging large number of objectsMay get very difficult to understand and debugNotion of components - Encapsulated abstractionsPluggability - a possibility - more work required


OO Languages & ReferencesSmalltalk, Eiffel, Python, C++, Java

www.bruceeckel.com – Thinking in Java

Introduction to OOP – Timothy Budd – www.cs.orst.edu/~cs582/slides

Many books on OO and OO SW development

Java Development Environment/UML – www.togethersoft.com

www.argouml.org

www.objecteering.com

Forte – www.forte.com, Jbuilder – available at the Univ.


Learning OO – Some guidelines for 541A.

• Firstly, there are numerous aspects of OO, UML and variations on the same…I do not expect you to master the notation..You can always look up a book and see the notation..Focus on the underlying modeling idea…what is being said about the problem..

• Develop skill to interpret somebody’s else diagrams..and also communicate your own notions..

• Lectures are an overview of key ideas…

• Programming knowledge is not a reqmt..so I will stay away from those concepts…You can always take an OO programming course..


OOA- A Generic View

• define use cases (Requirements)• extract candidate classes (Data modeling)• establish basic class relationships• define a class hierarchy (Data modeling)• identify attributes for each class (Data modeling)• specify methods that service the attributes (Process

modeling)• indicate how classes/objects are related (Process

modeling)• build a behavioral model – State diagrams (Behavioral

modeling)• Illustrate workflows with Activity Diagrams• Iterate


Togethersoft – An Intro!

Doing OO by hand can be cumbersome……….Good tools out there…

Rational Rose/Togethersoft

ArgoUML – not as sophisticated yet…….


UML Overview – Refer to the Textbook

Language for

Visualizing systemsSpecifying systemsConstructing systemsDocumenting systems

Features

Explicit model to facilitate communicationGraphical in natureWell-define semantics - unambiguousSupports both forward and reverse engineering - round trip engineering


Views in UMLDesign viewProcess viewImplementation viewDeployment viewUse case view Use case

view

Design view

Process view

Implementationview

Deploymentview

Vocabulary Functionality

System assemblyConfig. Mgmt

PerformanceScalabilityThroughput

TopologyDeliveryInstallaton

Behavior

Analysis

Unified view for all stages of the software development lifecycle..


Unified Modeling Language (UML)

User model viewUser model view. This view represents the system . This view represents the system (product) from the user’s (called “actors” in UML) (product) from the user’s (called “actors” in UML) perspective.perspective.

Structural model viewStructural model view. Data and functionality is viewed . Data and functionality is viewed from inside the system. That is, static structure (classes, from inside the system. That is, static structure (classes, objects, and relationships) is modeled.objects, and relationships) is modeled.

Behavioral model viewBehavioral model view. This part of the analysis model . This part of the analysis model represents the dynamic or behavioral aspects of the represents the dynamic or behavioral aspects of the system. system.

Implementation model viewImplementation model view. The structural and behavioral . The structural and behavioral aspects of the system are represented as they are to be aspects of the system are represented as they are to be built.built.

Environment model viewEnvironment model view. The structural and behavioral . The structural and behavioral aspects of the environment in which the system is to be aspects of the environment in which the system is to be implemented are represented.implemented are represented.


UML Overview (Contd)Building blocksThings Relationships DiagramsStructural ThingsClassesInterfacesCollaborationsUse casesActive classesComponentNodeBehavioral ThingsInteractions (messages)(action sequences)(links)States & state machinesGrouping ThingsPackagesFrameworksAnnotational ThingsNotesAdornments

DependencyAssociationGeneralizationRealization

Class diagramsObject diagramsUse case diagramsSequence diagramsCollaboration diagramState chartsActivity diagramsComponent diagramsDeployment diagrams

Italics denote implementationalDesign related..


HelloWorld Example

Import java.awt.Graphics

class Helloworld extends java.applet.Applet {

public void paint (Graphics g) {

g.drawString("Hello, World!",10,10);

}

}

Paint()

HelloWorld

g.drawstring("Hello, World!",10,10)


Applet

HelloWorld

Paint()

Graphics

Object

Component

Container

Panel

Applet

HelloWorld

ImageObserver

InheritanceHierarchy

Class Relationships


:Thread :Toolkit

:ComponentPeer

target:HelloWorld

Paint

HandleExpose

CallbackLoopRun

Run

Sequence diagram


HelloWorld

Java

Applet

Awt

Lang

Packaging diagram

Hello.html

Hello.jpg

HelloWorld.class

hello.java

Component diagram


Use Cases

a scenario that describes a “thread of usage” for a system

actors represent roles people or devices play as the system functions

users can play a number of different roles for a given scenario


Banking System UseCase examples…………


Use cases

Describes a set of sequences in which each sequence represents the interaction of things outside the system (its actors) with system itselfInvolves the interaction of actors with a coherent set of roles and the systemsActors - human and non human - major beneficiariesA use case can have many variantsA use case carries out some tangible amount of work


Developing a Use Case

What are the main tasks or functions that are performed by the actor?

What system information will the the actor acquire, produce or change?

Will the actor have to inform the system about changes in the external environment?

What information does the actor desire from the system?

Does the actor wish to be informed about unexpected changes?


Use cases (Contd.)

Use cases and scenarios (like class & instances) Use cases - what a system should do - Flow of

events - main flow and exceptions Use cases implemented by a collaboration of

classes - many objects participate to execute a

use case


Use case organisation

Use cases can be related via

Generalization InclusionExtension

Exhibit “relationships” similar to classes in general…..


Requirements & Use cases

Establish the context of the system by identifying actors that surround itFor each actor, consider the behavior that each expects or requires of the systemName these common behaviors as use casesFactor common behavior into new use cases, factor variants, organise use casesModel these use cases in Use-case diagramsAdorn with notes as necessary


UML: Use-Case Diagram


Use case diagrams

A use case diagrams shows all the usecases and actors

and their relationships

<<extends>>

<<extends>>

Place phonecall

Receive phonecall

Use scheduler

Place conf.Call

Receive additionalcall

CellularNetwork

User

MIS541AUniversity of Arizona Lecture 13 Object-Oriented Analysis -II.

Documents

Transcript of MIS541AUniversity of Arizona Lecture 13 Object-Oriented Analysis -II.