lecture 1
DESCRIPTION
lecture 1TRANSCRIPT
Currently:
-Software projects costs are going up and hardware costs are going down
-Software development time is getting longer and maintenance costs are getting higher
-Software error getting more frequent while hardware errors becomes almost rare.
- Software is developed using a rigid structured process that is inflexible.
Software project costs by development phase
Work step %
Requirements 3Design 8Programming 7Testing 15Maintenance 67
Modern Corporations are headed toward disaster
Any corporation decisions based on the output of incorrect software can threaten theability of a business to be financially strong tomorrow
Projects
Success 16.2%
Challenged 52.7%
Impaired 31.1%
Successful projects deliver full functionalityon-time and on-budget
Challenged projects deliver, but less than full functionality, over-budget, and late
Impaired are cancelled during development
Many projects are started with the wrong goals and find themselves having to start over again from the beginning.
Starting over does not support delivering at the original deliver date.
Standish Group found that for every 100 Projects that start, there are 94 restarts.
Approximately 28% of projects exhibit costoverruns of 150% to 200% of their original cost estimate.
A common joke about delivering software:
Do you want it on time or fully functional
What does the customer want
A customer wants a solution that:
Meets functional requirements
Adapts to the rapidly changing business environment.
Fits the run time (time/Space) constrains
A customer wants a software that is:
Maintainable Developed within budgeted resources ( time/ space / people ) Designed with appropriate longevity in mind
Classical
Object-Oriented
Development(structured, data modeling, ad hoc, etc )
AN OVERVIEW OF
METHODOLOGIES
14
15
Planning & Feasibility Study (optional)
Analysis - Requirements Determination
Design - Conceptual &
Physical
Construction (Purchase) & Testing
Implementation including Training &
Conversion
Evolution - Maintenance &
Enhancements
SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
System Life Cycle – Why?
• Need an agreed framework for the development– Identify milestones– Structure activities– Monitoring deliverables
System Life Cycle – Why?
• Advantages of agreed framework– An overall picture of the development process– A basis for development – Consistency in approach – Ensures quality
• Structure for planning, monitoring and controlling the development process
Problems with Traditional Approach
• Functional Decomposition– Functions and data separated– Data accessible by several processes
Major problem - data not protected
• Poor modularity• Data versus function
Problems with Traditional Approach
• Functional Decomposition• Poor modularity
– Ideally modules should be self-contained– Have well defined purpose– Be independent
Major problem – interdependency between modules
• Data versus function
METHODOLOGY OVERVIEW
• Methodology defined: The way something gets done. (i.e., The strategy, steps, directions, or actions.)
• Methodologies can be:• purchased• created• combination of both
• Thousands available for developing software-intensive information systems
20
SDLC versus Methodology
21
M #1 M #2…
SDLC =“GenericWay”
Methodology =“Specific Ways”
METHODOLOGY OVERVIEW
• Classifications of Methodologies• Traditional• Structured Analysis and Design• Information Modeling/Engineering• Object-Oriented
• Prototyping is a technique - (some say that it is a methodology)
22
The Traditional Methodology
• Applicable for small teams on small projects
• Functional perspective of a problem domain
• It is an informal, unstructured, unrepeatable, un-
measurable, ad-hoc way
• Tools used to support it are adequate (okay)23
(1950s - now)
Traditional Methodology Tools
24
-----------TECHNIQUES & TOOLS REPRESENTING-----------System Data ProcessFlows Logic _
Forms,
Layouts,
Grid Charts
System
Flowcharts
English Narrative,
Playscript,
Program Flowcharts,
HIPO Charts
Structured Analysis and Design Methodology
• Data Flow methodology (synonym)
• Compliments Structured Programming
• Very popular - perhaps the leading one for business
• Can be repeatable, measurable, & automated
• IDE & CASE s/w tools brought significant assistance
• 1) Yourdon, and 2) Gane & Sarson
• Functional perspective of a problem domain
• Describes the real world as data flowing through the information system, being transformed from inputs to outputs
25
(mid-1970s - now)
Structured Analysis and Design Methodology Tools
26
-----------TECHNIQUES & TOOLS REPRESENTING-----------System Data ProcessFlows Logic _
Data Dictionary,
Data Structure
Diagrams,
Entity-
Relationship
Diagrams
Data Flow
DiagramDecision Tree/Table,
Structured English,
Structure Charts,
Warnier/Orr Diagram
Reconcile Account Balances
Pay a
Bill
Withdraw Funds from an Account
Deposit Funds into an Account
Bank
Creditor
Employer
Other Income Source
Bank
Monthly Account Statements
Account Transactions
Bank Accounts
Account Transactions
Bill
Payment
Monthly Statement
Account Balance
Transaction
Prior Monthly Statement
New or Modified Monthly Statement
Modified Balance
Pay
Reimbursement
Withdraw or transfer
Deposit
Payment
Modified Balance
Current Balance
(adapted from Systems Analysis andDesign Methods, 4th Edition, Whittenand Bentley, McGraw-Hill, 1998)
(adapted from Systems Analysis andDesign Methods, 4th Edition, Whittenand Bentley, McGraw-Hill, 1998)
CUSTOMER
Customer Number (PK) Customer Name Shipping Address Billing Address Balance Due
ORDER
Order Number (PK) Order Date Order Total Cost Customer Number (FK)
INVENTORY PRODUCT
Product Number (PK) Product Name Product Unit of Measure Product Unit Price
ORDERED PRODUCT
Ordered Product ID (PK) . Order Number (FK) . Product Number (FK) Quantity Ordered Unit Price at Time of Order
has placed
sold
sold as
Information Modeling Methodology
• Data modeling & information engineering
(synonyms)
• Describes the real world by its data, the data’s
attributes, and the data relationships
• Can be repeatable, measurable, and automated
• Data perspective of the problem domain
29
(early-1980s - now)
Information Modeling Methodology Tools
30
-----------TECHNIQUES & TOOLS REPRESENTING-----------System Data ProcessFlows Logic _
Business
Area
Analysis,
Entity-
Relationship
Diagrams
Business
Area
Analysis,
Process
Model
Business Systems
Design
Object-Oriented Methodology
• Object modeling
• Compliments object-oriented programming
• Can be repeatable, measurable, & automated
• Object perspective of the problem domain
• Describes the real world by its objects, the attributes,
operations, and relationships
• Data & functions are encapsulated together
31
(mid/late-1980s - now)
Object-OrientedMethodology Tools
32
-----------TECHNIQUES & TOOLS REPRESENTING-----------System Data ProcessFlows Logic _
Object Model
Attributes
Object
Model
Static & Dynamic UML
Model Diagrams,
Operations,
Class relationships,
Object associations
Object-Oriented Methodology
• Revolutionary or Evolutionary?
• Most difficult aspect is the transition some people have
to make from a functional or data problem solving
strategy to an object problem solving strategy. Some
people must change from a “function think” or “data
think” to an “object think” strategy.
33
The Object-Orientated Approach
Phases (stages) of Development
• Inception• Elaboration• Construction• Transition
These indicate the state of the system at each phase NOT the activities involved at that point in
development
The Object-Orientated Approach
Phases (stages) of Development
1. Inception – the initial work required to set up and agree terms for the project.
Includes establishing the business case
– Feasibility
– Basic risk assessment
– Scope of the system to be delivered
The Object-Orientated Approach
Phases (stages) of Development
1. Inception
2. Elaboration – deals with putting the basic architecture of the system in place
– All main project risks are identified
3. Construction
4. Transition
The Object-Orientated Approach
Phases (stages) of Development
1. Inception
2. Elaboration
3. Construction – involves bulk of work on building the system
– Ends with beta-release of system
4. Transition
The Object-Orientated Approach
Phases (stages) of Development
1. Inception
2 Elaboration
3 Construction
4 Transition – process involved in transferring the system to the clients and users
Workflows• The activities implied by the stages in a traditional
structured modelling approach are referred to as Workflows in the object-orientated approach
• Workflows -– Requirements– Analysis– Design– Implementation– Testing
Workflows - activities
Inception
Elaboration
Construction
Transition
Requirements
Analysis
Design
Implementation
PHASES WORKFLOWS
The Object-Orientated Approach
Iterative Process - • Workflows may be carried out during any
phase of development• In each phase a range of workflows (activities)
may be carried out several times before moving on to the next phase
The Object-Orientated Approach
A range of workflows (activities) take place during the development of a system
Requirements
Analysis
Design
Implementation
Testing
The Object-Orientated Approach
I n c e p t i o n
E l a b o r a t i o n
C o n s t r u c t i o n
T r a n s i t i o n
An iterative process.
The ellipses represent iterations of workflows (requirements, analysis, design, implementation, testing)
A seamless Development Process• Phases less distinct than in a structured
approach• Difficult to say when one phase ends and
another begins• Driven by a single unifying idea – the object
The Object-Orientated Approach
The Object
• Basic building block• Objects in the real world translate into objects
in the software system– Physical (customers, products)– Conceptual (orders, reservations)– Organisation (companies, departments)– Implementation (GUI Windows)
• The foundation of all development work is the object
• No new system models introduced at different stages
• Early models developed and refined through the development process
• An iterative design process
The Object-Orientated Approach
Why OOP?/ Benefits•MaintainableOOP methods make code more maintainable. Identifying the source of errors becomes easier because objects are self-contained (encapsulation). The principles of good OOP design contribute to an application’s maintainability.•ReusableBecause objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes” (encapsulation).
47
• This feature makes it easy to reuse code in new systems. Messages provide a predefined interface to an object’s data and functionality.
• OOP languages, such as C# and VB.Net, make it easy to expand on the functionality of these “boxes” (polymorphism and inheritance), even if you don’t know much about their implementation (again, encapsulation).
48
• ScalableOO applications are more scalable then their structured programming roots.
• As an object’s interface provides a roadmap for reusing the object in new software, it also provides you with all the information you need to replace the object without affecting other code.
• This makes it easy to replace old and aging code with faster algorithms and newertechnology.
49
• Some DisadvantagesThe challenges of OOP exists mainly in the conversion of legacy systems that are built in structured programming languages.
• The technical challenge is not as big as the actual design challenge.
• The goal when converting is to minimize the effects of the structural systems on the OO nature of the new design, and this can sometimes be difficult.
50
Object Technology Principles
Common Methods of Organization
Abstraction
Encapsulation (Information Hiding)
Inheritance
Polymorphism
Message Communication
Associations
Reuse 51
• Objects and their characteristics
• Wholes and Parts
• Groups (Classes) and Members
52
Classification Theory(Common Methods of Organization)
53
• Common Methods of Organization
People are accustomed to thinking in terms
of...
• color• price• weight• engine• options...
Objects & Attributes
• number of doors• number of wheels• number of windows• number of lights• number of bolt type 1• number of bolt type 2• etc....
Wholes and PartsGroups & Members
VANS:• light utility• utility• passenger• etc...
54
• AbstractionA mental ability that permits people to view real-world
problem domains with varying degrees of detail depending on the current context of the problem.
• Helps people to think about what they are doing• Functional and Data abstraction
In Object-Oriented Technology the “package” is called an OBJECT The interface to each object is defined in such a way as to reveal as little as possible
about its inner workings Encapsulation allows [software] changes to be reliably made with limited effort
[Gannon, Hamlet, & Mills, 1987]
55
• Encapsulation (Information Hiding)
A technique in which data are packaged
together with their corresponding procedures.
cakeIngredients
Directions
2 eggs 4 cups flour1 cup milk 1 cup sugaretc.......
Pre-heat oven to 350; Putmilk, eggs, and sugarin 2 quart mixing bowl...
One cake please!
56
• InheritanceA mechanism for expressing similarity
between things thus simplifying their
definition.
• looks• behavior• attitudes• etc...
Person
Student Faculty Staff
Inheritance
• H O = water, ice, steam (liquid, solid, vapor)• Eating• Carbon compound crystallizes as graphite & diamond
57
• Polymorphism (“many forms”)
The ability to hide different implementations
behind a common interface.
The ability for two or more objects to respond
to the same request, each in its own way.
2
versusDoor#1
Door#2
Door#3
Door#1#2#3
• Polymorphism Two examples
0
5000
10000
15000
20000
25000
30000
North South East West
B L U E S K Y AI R L I N E S SalesReport January
B L U E S K Y AI R L I N E S SalesReport February
TEXT object
GRAPH object
IMAGE object
Object #1 PO object
Account object
Department object
Object #2
Object #3
Add
Add
Add
= add a line item to the PO
= increase $ Amount Balance
= hire a new employee
59
• Message Communication
OBJECT
OBJECT
OBJECT
OBJECT
Objects communicate via messages
60
• AssociationsThe union or connection of ideas or things.
(Objects need to interact with each other)
• same point in time
Billing StatementAdvertisement #1Advertisement #2
• under similar circumstances
crimescene
#1
crimescene
#2
crimescene
#n
Person
Student Faculty Staff
61
• Reuse
Varying Degrees of Reuse:
• complete or sharing
• copy, purchase or cloning
• partial or adjusting
• none
The ability to reuse objects
Software:• “Chips”• Components• Controls• Models
62
• Reuse
• Components must be reused three to five times before the costs of creating and supporting them are recovered• It costs one and a half to three times as much to create and support a single reusable component as to create a component for just one use• It costs 25% as much to use a reusable component as it does to create a new one• It takes two to three product cycles (about three years) before the benefits of reuse become significant
Software Reuse Costs and PayoffsOrenstein, D. “Code reuse: Reality doesn’t match promise”,
Computerworld, August 24, 1998, page 8.
O-O Systems Analysis & Design Methodology
• Data Model versus Function Model
• Analysis to Design Transition
• Maintaining Source Code
63
Three Classic Systems Analysis and Design Challenges:
VVVVVVVVVVVV
Colorado River
North Rim of theGrand Canyon
South Rim of theGrand Canyon
Classic Software Development Challenge #1:Multiple Models
DataModels
FunctionModels
User InteractionUser Interaction(Behavior)(Behavior)
VVVVVVVVVVVV
Colorado River
North Rim of theGrand Canyon
South Rim of theGrand Canyon
Classic Software Development Challenge #2:Model Transformation
DesignModels
AnalysisModels
Classic Software Development Challenge #3:Maintaining Source Code
Begin “Caller” Program Init x,y,z... Open (files/database) Read... Compute...
DO “Callee” with x,y,z
Update (files/database) Close (files/database) End Main Program
Procedure Callee Parameters x,y,z Compute... End Procedure
End Program
Spaghetti?
Who wrotethis code?
67
SOLUTION
Colorado River
ObjectTechnology
INTEGRATED MODEL(S)(function, data, behavior)
(analysis, design and implementation)
ROUND-TRIPENGINEERING
68
A SimplifiedObject-Oriented
Systems AnalysisMethodology
O-O Systems Analysis Methodology
1. Identify the information system’s purpose
2. Identify the information system’s actors and features
3. Identify Use Cases and create a Use Case Diagram
4. Identify Objects and their Classes and create a Class Diagram
5. Create Interaction/Scenario Diagrams
6. Create Detail Logic for Operations
7. Repeat activities 1-6 as required to refine the “blueprints”
A Simplified Object-Oriented Systems Analysis Methodology
Activities
Software Development’s “Separation of Concerns”
Problem Domain
Data Management System Interaction
Information System
Human Interaction
71
The Unified Modeling Language (UML)
Models and Notation
O-O Systems Analysis O-O Systems Analysis MethodologyMethodology
Subject Matter Expert & Notation
• Can you draw a stick figure of a person?
• Can you draw a picture of an automobile?
• Can you draw a picture of the space shuttle?
• Can you draw a picture of an Oopsla?
• Why not?
• Subject Matter Expert (SME)
• Notation - symbols used to communicate
72
73
Booch Jacobson Rumbaugh
“The 3 Amigos”
74
Information Systems Development
People Process
Technology(UML - notation & tools to use it)
75
The Object Management Group (OMG), formed in
1989, is a consortium of about 800 software
vendors, consultants and end user organizations
whose mission is to develop STANDARD interfaces
for INTEROPERABLE software components in
HETEROGENEOUS computing environments.
Version 1.1 of the UML was adopted as an OMG Standard on November 14, 1997
www.omg.org
The OMG Revision Task Force released UML Version 1.3 in the Fall of 1998
Unified Modelling Language - UML
• A notation or language for development• Not a development method• Set of diagrammatic techniques• Industry standard for modelling OO systems• UML Creators – Ivar Jacobson, Grady Booch, James
Rumbaugh
Principal UML ModelsModel View of the system
Use case How the system interacts with its users.
Class The data elements in the system and the relationships between them.
Interaction (sequence and collaboration)
How a use case affects all the objects that are involved in it.
State How the different objects of a single class behave through all the use cases in which the class in involved.
Activity The sequence of activities that make up a process.
Component The different components of the system and the dependencies between them.
Deployment The software and hardware elements of the system and the physical relationships between them.
The UML Provides Standardized Diagrams
DeploymentDiagram
DeploymentDiagram
Use CaseDiagrams
Use CaseDiagramsUse Case
Diagrams
Use CaseDiagramsUse Case
Diagrams
Use CaseDiagrams
ScenarioDiagrams
ScenarioDiagramsScenario
Diagrams
ScenarioDiagramsSequence
Diagrams
SequenceDiagrams
StateDiagrams
StateDiagramsState
Diagrams
StateDiagramsState
Diagrams
StateDiagrams
ComponentDiagrams
ComponentDiagramsComponent
Diagrams
ComponentDiagramsComponentDiagrams
ComponentDiagrams
Model
StateDiagrams
StateDiagramsState
Diagrams
StateDiagramsObject
Diagrams
ObjectDiagrams
ScenarioDiagrams
ScenarioDiagramsScenario
Diagrams
ScenarioDiagramsCollaboration
Diagrams
CollaborationDiagrams
Use CaseDiagrams
Use CaseDiagramsUse Case
Diagrams
Use CaseDiagramsActivity
Diagrams
ActivityDiagrams
StateDiagrams
StateDiagramsState
Diagrams
StateDiagramsClass
Diagrams
ClassDiagrams
Unified Modeling Language (UML)
“A graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software intensive system.” [Booch]
UML in One Sentence
The UML is a graphical language for• visualizing• specifying• constructing• documentingartifacts of a software-intensive system.
Visualizing
• explicit model facilitates communication• some structures transcend (pass or more) what
can be represented in programming language• each symbol has well-defined semantics behind it
Specifying
The UML addresses the specification of all important analysis, design, and implementation decisions.
Constructing
• Forward engineering: generation of code from model into programming language
• Reverse engineering: reconstructing model from implementation
• Round-trip engineering: going both ways
UML and Blueprints
The UML provides a standard way to write a system’s “blueprints” to account for
• conceptual things (business processes, system functions)
• concrete things (C++/Java classes, database schemas, reusable software components)
In UML, we have a state diagram for dynamic behavior. The state diagram shows:
-State-Transition-Event-Condition-Action
Construct Description Syntax
class a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.
interface a named set of operations that characterize the behavior of an element.
component a modular, replaceable and significant part of a system that packages implementation and exposes a set of interfaces.
node a run-time physical object that represents a computational resource.
«interface»
Structural Modeling: Core Elements
Structural Modeling: Core Elements (Continued)
Construct Description Syntax
constraint a semantic condition or restriction.
{constra in t}
package orsubsystem
a holder for grouping elements
Construct Description Syntax
association a relationship between two or more classifiers that involves connections among their instances.
aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.
generalization a taxonomic relationship between a more general and a more specific element.
dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).
Structural Modeling: Core Relationships
(open arrow)
Composition
Construct Description Syntax
realization a relationship between a specification and its implementation.
Structural Modeling: Core Relationships (Continued)
(closed arrow)
Realization relationship connects a model element such as a class, to another model element, such as an interface that supplies its behavioral specification but not its structure or implementation. The client must support ( by inheritance or by direct declaration) at least all the operations that the supplier has.
Class Diagram Concepts
• A static model that shows the classes and relationships among classes that remain constant in the system over time
Class Diagram for Manage Appointment
HW1: due date one week from today:Model the following using a class diagram:Your company writes student and course data management software for universities. You are writing a data management package for a university with several campuses. Employees in the administration office of each campus has to enter several student and class input parameters; these will be stored in a central database in the main campus. CORBA has been chosen to send this data. There will be two kinds of data: per student data, and per course data. For each student, the administration employee will enter a social security number, a 3 line home address, and the current semester’s grades (the student will have taken at least one class, and no more than 5 classes). If the student is also a university employee, the administration employee will enter the student’s salary. For each course, the administration employee will enter the instructor’s name, the time of day the course meets, the days of the week the course meets, the date and time of the final exam, and the number of hours of the course. The administration employee will also enter a student name and social security number for each student in the course.The central database software will provide values in return. For each student, the student’s new GPA (based on existing plus new classes) will be returned, along with total number of courses the student has taken at the university. For each course, the central database software will provide the total number of courses the instructor is teaching this semester. If the final exam time entered does not match that stored in the central database, then the final exam time variable will be corrected
The 9 Diagrams of the UML ClassClass ObjectObject Use-CaseUse-Case Interaction/Scenario Diagrams:Interaction/Scenario Diagrams:
– SequenceSequence
– CollaborationCollaboration
State [-Transition]State [-Transition] ActivityActivity ComponentComponent DeploymentDeployment
Implementation(Static)
Behavior
Static
A Package is used for Model Management
95
UML
Diagrams
96
97
98
99
100
101
102
103
“The Big Picture”
A Video Store UML
Class Diagram
104
105
106
107
108
109
End of
“The Big Picture”
QUITTING TIME