Beyond Object-oriented Methodologies
W
Shared by: rogerholland
Categories
Tags
object-oriented programming, object-oriented development, object-oriented analysis and design, object-oriented design, use cases, software development, software engineering, object-oriented methodologies, object orientation, object-oriented analysis, how to, agile methodologies, object-oriented software, design patterns, extreme programming
-
Stats
- views:
- 16
- posted:
- 9/2/2009
- language:
- English
- pages:
- 12
Document Sample


Object-oriented Methodologies
and
Beyond!
Goal, Agent, and Aspect-oriented
Approaches
Object-oriented Approaches
Object-oriented approaches began with the invention
of object-oriented programming languages in the
1960s by Johan Dahl and Kristen Nygaard at the
Norwegian Computing Center, Oslo, Norway
Created SIMULA I (1962-65) and Simula 67 (1967)
first object-oriented languages
Simula 67 introduced most of the key concepts of
object-oriented programming:
objects and classes
subclasses (inheritance)
virtual procedures
Simula 67 compilers started to appear for UNIVAC,
IBM, Control Data, Burroughs, DEC and other
computers in the early 1970s
Alan Kay's group at Xerox PARC used Simula as a
platform for their development of Smalltalk (1970s)
Bjarne Stroustrup started his development of C++
(1980s) by bringing the key concepts of Simula into
the C programming language
US Department of Defense promoted ADA (1980s)
object-approach (no inheritance)
Onto Object-oriented Analysis and Design
Towards the mid-80s, the benefits of object-oriented
programming began to gain recognition
object design approaches are developed and adopted
object analysis was not developed, yet
structured analysis was available (i.e.,
functional analysis by Ross, DeMarco,
Yourdon, Ward/Mellor
this could result in a functional analysis phase with
an object-oriented design phase
difficult
no direct relationship between the two sets
hard to trace requirements
object-oriented design obtained after translation
can lack abstraction
limited to the encapsulation of low-level
objects
Early 1990s
~fifty different object-oriented methods proposed
multitude of interpretations of exactly what
an object is
object-oriented competition ensued
Booch and OMT (Object Modeling Technique)
won the object competition
The evolution continues
next versions of the Booch and OMT
methods, Booch'93 and OMT-2, were more
similar to one another
Booch'93 focused on implementation,
while OMT-2 concentrated on analysis
and abstraction
Unified Method version 0.8 presented at the Object-
Oriented Programming, Systems, Languages, and
Applications (OOPSLA) conference in 1995
Booch '93 + OMT-2
Jacobson (use cases), Booch, Rumbaugh "The Three
Amigos" unified method version 0.9 1996
OOAD approaches have been available/in use for
over 15 years
During that time, software systems have continued to
increase in complexity
heterogeneous, distributed, autonomous
control, stakeholders involved throughout,
web based, systems that need to change
Object-oriented approaches don't take care of all the
problems
Goal, Agent, and Aspect-oriented approaches are being
proposed to solve some problems
Goal-oriented Approaches
Example. Problem in Requirements Phase
We know that
Customers have business goals that need to be met
Some of their goals can be met with a computer
system; others by people doing a task manually
In the early stages of developing a system,
customers do not necessarily know exactly what
they need the system to do
For a Digital Library System
when asked, the may say something like the system
should
provide fast and convenient searching
capabilities
support reference requests
allow the users to search the catalog efficiently
enforce IP of the owners
be easy to use
…
These statements are really high level objectives, or
goals, for the system; they are not "good"
requirements
"good" requirements are correct, complete,
concise, unambiguous, verifiable, traceable,
prioritized, …
Goal-oriented approaches begin the software
development process by capturing the stakeholders'
goals and subsequently refine them into requirements
the goals are important and need to be explicitly
modeled and traced to/from
Moderately …
Easy to Use -
Priced
Variety of Graphical Configurable
Interface User Interface
Options Interface
Configuration Configuration
for Expert for Novice
Legend
softgoal and decomposition
NFR Framework Softgoal Interdependency Graph
An excellent introduction to goal oriented approaches
is by A. van Lamsweerde, "Goal-Oriented
Requirements Engineering: A Guided Tour"
Agent-oriented Approaches
Example. Problem in modeling autonomous,
interacting, distributed systems
We know that
people/systems depend on other people/systems
to accomplish tasks or goals
people/systems make commitments to
provide a task or meet a goal
people/systems have strategies to ensure their
goals are accomplished
Agent-oriented approaches model people and systems
as agents
an agent has the following properties:
autonomy, beliefs, goals, commitments, and
strategy
Agents vs. Objects
agents are regarded as a possible successor of
objects since they can improve the abstractions of
active entities
objects are successfully used as abstractions
for passive entities (e.g. a house) in the real-
world
Agents also support structures for representing
beliefs and commitments
Objects are controlled from the outside; agents
that have autonomous behavior which can't be
directly controllable from the outside
agents can say ``no'' to a request
Some examples of agents include:
- The animated paperclip agent in Microsoft Office
- Computer viruses (destructive agents)
- Artificial players or actors in computer games and
simulations
Define
Agents
Deliver System
Artifacts Define Goals
Define System (with COTS)
Requirements
Deliver High Quality
System
(with COTS)
…
Deliver Within Budget
Customer Deliver Within Schedule Development Component
System House
Deliver On Time
Component
Deliver Within Budget
Deliver High Quality
System
Component
Deliver
Validate System Component
Artifacts Artifacts
Component
Sales
Legend Component
Vendor
Agent Hardgoal Dependency
Relationship
Task Softgoal
High-level Strategic Dependency and Rationale Models of CARE (in the i* notation)
Aspect-oriented Approaches
Example. Problem in modeling non-functional
properties in a system
Consider the following design example
1. Based on the functional requirements, a design model
is created with classes A,B,C
* 1 * *
A B C
- assume the design has high cohesion, low coupling
2. Later, a new requirement is added for providing
security (e.g., encryption, decryption)
Adding in the new capabilities can:
- decrease cohesion
- increase coupling
- cause significant re-work
The aspect-oriented approaches provide mechanisms
to:
describe the security functionality separately
(called an aspect)
indicate where the aspect (or part of the aspect)
should be included in the reference model (i.e.
the original model)
weave the aspect into the reference model
extract the aspect back out of the reference
model
NB. The aspect-oriented community uses the terms
"tangling" and "cross-cutting" instead of coupling
* 1 * *
A B C
encryption(p1:t1, pn:t2): string
decryption(p1:t3): string
D
(security)
References
History of Object-oriented programming languages:
http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.ht
ml
History of Object-oriented Analysis and Design:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dniuml/html/analysisdesignmethods.asp
A. van Lamsweerde, "Goal-Oriented Requirements Engineering: A Guided
Tour". Invited minitutorial, Proc. RE'01 - International Joint Conference
on Requirements Engineering, Toronto, IEEE, August 2001, pp.249-263.
- see also research by Anton, Chung, Yu
Agent-oriented Software Engineering
http://www.jfipa.org/publications/AgentOrientedSoftwareEngineering
- see also research by Jennings, Wooldridge
Aspect-oriented Software Engineering
http://aosd.net
Related docs
Get documents about "