SE 430 -- Object-oriented Modeling -- Session 1

Topics -- Software Development, Software Models

(L) 1-5 (P) 1-2

Software

includes all documentation artifacts necessary to install, use, develop and maintain programs

Software Engineering Methodology

"A process for the organized production of software using a collection of predefined techniques and notational convention." Rumbaugh

Software is developed in manageable stages

Software Development Life Cycle (SDLC)

Stage / Activity
Requirements analysis and definition / Take steps to understand the problem
The system's services, constraints and goals
are identified by agreement with the system users and owners.
System and software design / Partition requirements into hardware/software systems

Implementation / Program coding and unit testing
System testing / Test composite system
Operation and maintenance / Typically the longest part of the life cycle

Try to be correct at the beginning of the software development cycle:

Alan M Davis "Software Requirements Analysis & Specification"

  1. Many errors remain undetected until well after the stage at which they are made
  2. The later in the life cycle that an error is detected, the more expensive it is to repair
  3. Most software errors can be found by inspection
  4. 56% of all detected bugs are traceable to errors made during requirements stage.

The early stages of software development should:

  • Clarify requirements
  • provide a basis of agreement with user/owner/co-developers
  • provide a framework for later design and implementation
  • help write and maintain the software

Software Models

Increase communication capability by including pictures, diagrams, graphs, etc.

A Model is intended as

an abstraction of something for the purpose of understanding it before building it. (Rumbaugh)

a simplification of reality, created in order to better understand the system being created. (Booch)

Models are used to:

  • reduce complexity
  • aid visualization
  • aid communication
  • test before building

UNIFIED MODELING LANGUAGE (UML)

a general-purpose visual modeling language designed to visualize, specify, document and construct a software system.

with extensibility and specialization mechanisms that provides a formal basis for understanding the model

What does UML contribute?

A widely-accepted notational system for modeling both the real-world and object-oriented software concepts.

Analysis / Design
What / How
Investigate the problem / Create a solution

Common factors of software engineering (Ian Sommerville)

  • Software built by teams
  • Use engineering principals
  • Consists of technical and non-technical aspects

Functional Model -- Process oriented methodology

  • Main emphasis is on capturing Input, Process, and Output
  • The idea is to study behavior to derive data structures and programs
  • *Develop a "global" knowledge to control procedures by using:
  • structured analysis and structured design

Structured analysis -- model a system with data flow diagrams for the

storage of data

flow of data

processes that respond to and change data


Potential pitfalls with structured analysis

  • analysis paralysis
  • design of structure chart from data flow model was not obvious nor seamless
  • any small change in requirements could produce large changes in code
  • data flow diagrams did not ensure complete and accurate data
  • inconsistent reports
  • update anomalies
  • Hard to map the structured analysis to the programs created. (Trace-ability problem)

Structured design -- factor a program into a top-down hierarchy of modules

Where each module should be:

  • Cohesive-- a module should do a specific function
  • Loosely coupled -- minimize data and parameter passing
  • The top-level is the top level manager of the system.
  • Lower hierarchical levels further subdivide the allocated work to lower level managers.
  • The design concept is one of transform analysis where the input and output streams have one clearly defined central process.

Data Modeling -- a data-centered methodology

Study the system's data needs independently of how the data is currently used.

Data modeling technique

  • identify business entities
  • attribute the data elements that describe these entities
  • specify the relationships that exist between entities

------


Data modeling focuses on

  • accurate, up-to-date data
  • today's output requirements
  • meeting future output requirements without drastic changes (because data is already there)

Data Modeling did not completely solve certain Problems:

Not clear how to connect process to the data model

An Object-Oriented System

Depends on "local" knowledge of objects to accomplish tasks.

There are very few things an object can do on its own, in order to accomplish any significant task, objects must communicate with other objects.

Emphasis on Abstraction

Model relevant attributes and behavior of a given entity for a particular purpose Focus on what an object "is" and "does.” Class defines both behavior and state.

Properties of a Good Abstraction

Well named / The name accurately communicates the nature of the abstraction
Coherent / The abstraction contains a related set of attributes and behavior that makes sense and is needed and expected in a given setting
Accurate / The abstraction contains only attributes or behavior that are displayed by the entity being modeled.
Minimal / The abstraction does not contain attributes or behavior extraneous to the purpose for which it is defined.
Complete / The abstraction contains all the attributes and behavior necessary to accomplish its intended purpose.
.

Three levels of modeling detail

Essential --concepts of the business without reference to implementation technology.

Specification --the characteristics of software that will meet the requirements of a business solution.

Implementation --the construction of the software


Difference between Class and Object

Class --

A description of a set of objects which have something in common.

Class is also a programming concept used to define objects that have the same attributes, operations, relationships and semantics.

Object --

Is an instance of a Class.

Objects are created from a Class at run-time. Since Classes have state, an object retains information about its attributes for some indefinite time. This is different than functions or subprograms

Object Oriented Concepts

Encapsulation

Grouping of related ideas into one unit referred to by a single name.

“information hiding” -- information is hidden about data and implementation so that clients only have to know the interface of the class

Class defines an interface and an implementation -- operation and attributes. Attributes and operations are accessible only through the interface. De-couple content of information from its form of representation.

Separate “what” an entity does from the “how” so less has to be known in order to use the class.

The implementation can be changed without affecting a client's knowledge of the interface.

Coding revisions to a class should have only a local effect and not cascade to other dependent objects.

Loose coupling enforced. Design decisions are localized

Object Identity

Every object has its own identity (regardless of its class or attribute values).

Usually implemented with a pointer reference (object-handle)

The object-handle is unique for every object.

Generalization - Specialization

Define the state and behavior properties once in a general super-class (Vehicle) then reuse them through inheritance in a more specific sub-class (Car, Truck)

Use inheritance to reduce repetition for hierarchical relationships within designs and within programs

Inheritance enables a class to receive all the attributes and operations of its parent(s)

A specialized sub-class may also add its own properties and override some inherited properties

Composition

use components that interact to accomplish a task

  • Build complex “whole” systems by assembling simpler “parts” by association or aggregation

Type promotion

OO languages support substitution of a specialized object as a more general type.

Can refer to an Car instance as either a Vehicle or a Car.

De-couples generic code from the existence of a particular specialization.

Message Passing

Objects communicate to other objects via message passing.

Very few objects can accomplish the necessary tasks by themselves. They have to work with other objects.

Messages contain the object-handle, name of the operation that is to be performed and any additional arguments that should be used in the operation.

The message sender does not have to know the exact class of the receiver

Polymorphism

Each class may perform the same named operation differently.

Usually Implemented at execution time with dynamic-binding, exact code to execute is determined at run-time so then objects respond based on what they actually are.

Tell a vehicle to move and it will move like a car if it is a Car or a truck if it is a Truck.

De-couples generic code from the existence of a particular specialization.

Representation Continuity

Same types of diagrams are used in both analysis and design.

Design elaborates the diagrams discovered during analysis. (Particularly true for Class diagrams, Use Case Diagrams and Interaction Diagrams).

Object oriented approach to analysis

appropriate programming structures are based on relevant objects of the application domain

organize software as a collection of objects containing data structure and behavior

build an object model of an application domain

add implementation details to the model during design

OO compared to traditional software development (Rumbaugh OMT)

Remove programming language concepts. Emphasize language of the domain.

OO Analysis should emphasize

front-end conceptual issues (analysis)

data structure before function

be iterative not sequential

language of the application domain

OO Analysis should not emphasize

back-end implementation (code)

Object-oriented development (Rumbaugh OMT)

A seamless progression of objects by:

  1. identifying real-world object classes in a domain
  2. using same notation & language throughout development stages (trace-ability)
  3. adding detail to the object classes with each development stage
  4. adding necessary implementation objects at design stages.

Software Development Stages (Rumbaugh OMT)

Stage / Activity
Analysis
Produce a document of what the system must do, not how to do it. / start with a problem statement
build real-world models of domain concepts
verify, iterate and refine the models
System design
high-level design of the architectural structure to solve the problem / Strategy for allocating software/hardware resources
Organize problem components into subsystems
Consider performance and concurrency characteristics
Object design
Produce a design document using the same classes defined by analysis. / Avoid using any particular programming language
Objects derived from analysis may require additional details before implementation. Where necessary, add
Data structures
Algorithms
Computer domain concepts
Implementation
Transform classes into hardware and software code. / Programming language
database technology
network configuration

Prototypes & Models to help clarify requirements

  • use when requirements are vague or ambiguous
  • user interface languages and/or high level 4GL
  • iterate through successive changes until the users can describe the target system

------

TogetherSoft /EnterpriseUML Modeling tool

What is "Design"?

Work with someone else.

Take no more than 15 - 20 minutes.

Sketch a design of a small, one-branch bank.

(the whole thing, not just the computer part)

The design can include images and/or text.

Limit the design to a single sheet of paper.

You should be able to show this piece of paper to pretty much anyone on the street (see note), and they would recognize the bank's basic design.

NOTE:

Most people in the street will not be familiar with a OOD, DFD, ERD, or Structure Chart.

The class will discuss if and how the sketches capture the design of a small, one-branch bank.

1