1
2
Go To Slid 71 Statecharts
Principals of Object Orientation Chapter 20,21,22
3
What is an Object? • A thing • A Visible Thing • It has: – Identity – Behavior – State – this includes • static properties and dynamic values of these properties 4
What is an Object? • An object has a state, behavior and identity. • Structure and behavior of similar objects are defined in a common CLASS.
5
What is an Object • Behavior of objects is achieved via its methods. • The state of an object is realized thought the contents of its data. • Objects can communicate via messaging protocols 6
Object Behavior - Object Life Cycle Initialize Initialize Object Object Wait Waitfor for Request Request Handle Handle Request Request
Terminate Terminate Object Object 7
Principals of OO • Abstraction – Denotes the essential characteristics of an object that distinguishes it from all kinds of objects. • What does the object do without any implication on how does it do it
8
Principals of OO • Encapsulation – The process of Compartmentalizing the elements of an object that constitute its structure and behavior • Data hiding • Localize design decisions
– What are the encapsulated elements? 9
Principals of OO • Modularity – OO is different form Structured – In Structured Paradigm module and function are the same – In OO Paradigm Classes and objects are the lowest form of Modularity. • A module could have multiple classes
10
Principals of OO • Hierarchy – Ranking of ordering of abstraction • An object is a class
• Inheritance (is a) – The relationship between classes • One class share the structure and behavior of one or more classes
11
Inheritance Class: Furniture
Object: Chair
Cost Dimensions Weight Color
Cost Chair inherits all attributes and operations of class Furniture
Dimensions Weight Color
Buy Sell
Buy Sell
12
Principals of OO • Polymorphism – The same operation may behave differently on different classes. • Example + sign
• Aggregation (part of) – “a-part-of” relationship in which objects representation the components of something are associated with an object representing the entire assembly 13
Principals of OO • Identifying Classes – – – – – –
External Entities (devices, people) Things (reports, forms, Features, Estimates) Occurrences or Events (Moving) Roles (Mangers, Engineers, Group, Team) Places (Loading dock, Shipping Floor) Structures(Computers) 14
OO Analysis Chapter 21
15
OO Modeling • OO has its own Modeling Techniques • UML – Unified Modeling Language – Grady Booch Method – James Rumbaugh Method – Ivar Jacobson Method
16
OO Modeling • Grady Booch Method – Micro Development Process • Defines a set of analysis tasks that are re-applied in the Macro process • Identifies classes, objects, and relationships
– Macro development Process • Refine
17
OO Modeling • James Rumbaugh Method – Object Modeling Technique (OMT) for • Analysis, creates: – The object model – objects, classes, and relationships – The dynamic model – objects and system behavior – The Functional Model – DFD like
• System level design • Object level design
18
OO Modeling • Ivar Jacobson Method – Object Oriented Software Engineering – Use Cases oriented method
19
OO Analysis Steps • • • • • • • •
Elicit Requirements Identify Scenarios Select Classes and Objects Identify Attributes and operations for each object Define Structures and Hierarchies for Classes Build an Object Relationship model Build an Object behavior model Review the OO analysis model against Use cases or scenarios. 20
The Unified Modeling Language Chapter 21
21
Why do we model? • • • •
Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage complexity Reduce time-to-market for business problem solutions • Decrease development costs • Manage the risk of mistakes
22
Why do we model graphically?
• Graphics reveal data. • 1 bitmap = 1 megaword. – Anonymous visual modeler
23
What is UML • The UML is a graphical language for – Specifying, can be used to communicate "what" is required of a system, and "how" a system may be realized.
– Visualizing, it can be used to visually depict a system before it is realized
– Constructing, can be used to guide the realization of a system similar to a "blueprint".
– Documenting, can be used for capturing knowledge about a system throughout its life-cycle
the artifacts of software systems 24
What is UML • Added to the list of OMG adopted technologies in November 1997 as UML 1.1 • Most recent minor revision is UML 1.3, adopted in November 1999. • UML 2.0 is under review
25
OMG UML Evolution UML 2.0
2002 (planned major revision)
[backward compatible] 2001 (planned minor revision)
UML 1.5 ISO Publicly Available Specification
Q4 2000 (planned minor revision)
UML 1.4
[read only] UML 1.3
1999
Editorial revision with no significant technical changes.
1998
1997 (adopted by OMG)
The expected result of OMG's formal liaison with ISO. UML 1.2
UML 1.1
26
OMG UML Contributors Aonix Colorado State University Computer Associates Concept Five Data Access EDS Enea Data Hewlett-Packard IBM I-Logix InLine Software Intellicorp Kabira Technologies Klasse Objecten Lockheed Martin
Microsoft ObjecTime Oracle Ptech OAO Technology Solutions Rational Software Reich SAP Softeam Sterling Software Sun Taskon Telelogic Unisys … 27
OMG UML 1.3 Specification • • • •
UML Summary UML Semantics UML Notation Guide UML Standard Profiles – Software Development Processes – Business Modeling • UML CORBAfacility Interface Definition • UML XML Metadata Interchange DTD • Object Constraint Language
28
the Language • language = syntax + semantics – syntax = how the symbols should look and how are they combined (i.e words in natural language) – semantics = rules that tells us the meanings of each symbol.
• UML Notation Guide – defines UML’s graphic syntax • UML Semantics – defines UML’s semantics 29
UML Views • User model view – The system from the user’s perspective. • Use-cases
• Structural model view – Static structure
UML Analysis Modeling
• Classes, objects, and relationships
• Behavioral model view – Dynamic aspect of the system including collaborations between elements identified in the user-model and the structural model views.
• Implementation model view
UML Design Modeling
– Describes the structural and behavioral aspects of the implementation.
• Environment model view – Shows the actual hardware that is required to implement the 30 solution.
UML Diagrams Inter object behavior Diagram
UML decomposition dimension
Use case diagram
Functional
Class diagram
Static
Collaboration diagram
Dynamic
Sequence diagram
Dynamic
Intra object behavior Statecharts
Dynamic
31
Language Architecture • Metamodel architecture • Package structure
32
Metamodel Architecture MOF Meta-Metamodel «metaclass» Attribute
«metaclass» Class
«instanceOf»
«metaclass» Operation
«instanceOf» «instanceOf»
UML Metamodel
«metaclass» Attribute
«metaclass» Class
«instanceOf»
Analysis Model The attribute fare of the PassengerTicket class is an instance of the metaclass Attribute.
PassengerTicket +issuedBy : Airline +issuingAgent : TravelAgent +fare : Currency +tax : Currency +total() +issue() +surrender() +refund()
«metaclass» Operation
The operation issue of the PassengerTicket class is an instance of the metaclass Operation.
«instanceOf»
45723990550: PassengerTicket
From Modeling CORBA Applications with UML chapter in [Siegel 00].
+issuedBy : Airline = AcmeAirlines +issuingAgent : TravelAgent = TerrificTravel +fare : Currency = 1050.00 +tax : Currency = 57.56
Represents the User Object layer of the 4-layer metamodel architecture pattern.
33
Package Structure UML
Behavioral Elements
Model Management
dependency Foundation
package
34
UML Views • User model view • Use-cases • Structural model view • Behavioral model view • Implementation model view • Environment model view
35
Use Case Modeling • Defines the functional and operational requirements of the system. • Takes the place of the DFD in traditional analysis. • Model the system from the end-user's perspective. • Use case diagrams show different levels of abstraction, just like DFDs. • Objectives: – Define the functional and operational requirements of the system (product) by defining a scenario of usage. (These should be agreed upon by the users and developers.) – Describes how the system and the users will interact. 36
What is use case modeling?
• use case model: a view of a system that emphasizes the behavior as it appears to outside users. • A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).
37
Use Case Modeling: Core Elements Construct Description use case
actor
A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. A coherent set of roles that users of use cases play when interacting with these use cases.
Syntax
UseCaseName
ActorName
system boundary
Represents the boundary between the physical system and the actors who interact with the physical system.
38
Use Case Modeling: Core Relationships
Construct
Description
Syntax
association
The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other. extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case. generalization A taxonomic relationship between a more general use case and a more specific use case.
39
Use Case Modeling: Core Relationships (cont’d) Construct
Description
include
An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.
Syntax
40
Use Case Diagram Tour • Shows use cases, actor and their relationships • Use case internals can be specified by text and/or interaction diagrams • Kinds – use case diagram – use case description
41
Use Case Diagram Telephone Catalog
Check status
Place order
Salesperson
Fill orders Shipping Clerk
Customer Establish credit
Supervisor
42
Use Case Relationships Supply Customer Data
«include»
Order Product
«include»
Arrange Payment
«include»
Place Order 1
*
Extension points additional requests :
after creation of the order
«extend»
the salesperson asks for the catalog
Request Catalog
43
Actor Relationships 1
*
Place Order
Salesperson
1
*
Establish Credit
Supervisor
44
Use Case Description: Change Flight nActors:
traveler, client account db, airline reservation system
nPreconditions:
Traveler has logged on to the system and selected ‘change flight itinerary’ option •
nBasic
course
System retrieves traveler’s account and flight itinerary from client account database • System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. • System asks traveler for new departure and destination information; traveler provides information. • If flights are available then • … • System displays transaction summary. •
nAlternative •
courses
If no flights are available then … 45
When to model use cases • Model user requirements with use cases. • Model test scenarios with use cases. • If you are using a use-case driven method – start with use cases and derive your structural and behavioral models from it.
• If you are not using a use-case driven method – make sure that your use cases are consistent with your structural and behavioral models.
46
Use Case Modeling Tips • Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers • When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams (see Lecture 2) • Factor out common usages that are required by multiple use cases – If the usage is required use – If the base use case is complete and the usage may be optional, consider use
• A use case diagram should – contain only use cases at the same level of abstraction – include only actors who are required
47
Example: Online HR System Online HR System Locate Employees
Update Employee Profile
Manager
{if currentMonth = Oct.} Update Benefits
Employee
Healthcare Plan System
{readOnly}
Access Travel System
Access Pay Records
Insurance Plan System
48
Online HR System: Use Case Relationships Update Medical Plan
Update Dental Plan
Update Insurance Plan
Update Benefits
Employee
______________ Extension points benefit options: after required enrollments employee requests reimbursement option Elect Reimbursement for Healthcare
extension point name and location employee requests stock purchase option
Elect Stock Purchase
extension condition
49
Online HR System: Update Benefits Use Case : employee, employee account db, healthcare plan system,
nActors
insurance plan system nPreconditions:
Employee has logged on to the system and selected ‘update benefits’ option •
nBasic •
course
System retrieves employee account from employee account db
System asks employee to select medical plan type; include Update Medical Plan. •
System asks employee to select dental plan type; include Update Dental Plan. • … •
nAlternative
courses
If health plan is not available in the employee’s area the employee is informed and asked to select another plan... •
50
UML Views • User model view • Structural model view – Class Diagram
• Behavioral model view • Implementation model view • Environment model view
51
What is structural modeling?
• Structural model: a view of a system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations.
52
Structural Modeling: Core Elements 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 physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. node a run-time physical object that represents a computational resource.
«interface»
53
Relationships in UML • Association – To permit the exchange of messages – Default is bi-directional (support messages in either way) – When an object uses the services of another object but does not own it. – Client server 54
Relationships in UML • Aggregation (diamond at the owner) – One object contains another. – The aggregation class is referred to as the owner, or whole. – The aggregated class is the owned, or part. – Example: a window has a drawing area, the drawing area can't stand on its own. 55
Relationships in UML • Composition (filled in diamond at the owner) – Strong aggregation – the owner is responsible for creating and destroying of the part object. – Composite object that creates it’s components – Example: an active object with multiple threads of control. 56
Relationships in UML • Generalization (Inheritance) – Is-a-kind-of relationship – One class is a specialization of another – The child has all the characteristics of a parent and it might specialize them – Example: A mammal is-a-kind-of Animal A cat is-a-kind-of Animal
57
Relationships in UML • Dependency – – – – – –
58
Structural Modeling: Core Relationships Construct
Description
Syntax
a relationship between two or more classifiers that involves connections among their instances. A special form of association that aggregation 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. a relationship between two modeling dependency elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element). association
59
Structural Modeling: Core Relationships (cont’d) Construct
Description
realization
a relationship between a specification and its implementation.
Syntax
60
61
Structural Diagram Tour • Show the static structure of the model – the entities that exist (e.g., classes, interfaces, components, nodes) – internal structure – relationship to other entities
• Do not show – temporal information
• Kinds – static structural diagrams • class diagram • object diagram
– implementation diagrams • component diagram • deployment diagram
62
Static Structural Diagrams • Shows a graph of classifier elements connected by static relationships. • kinds – class diagram: classifier view – object diagram: instance view 63
Associations Job 1..∗ ∗ Company employer employee
Job salary
Person
boss
worker ∗
0..1
Manages
Person Account
{X or} Corporation
64
Composition Window scrollbar [2]: Slider title: Header body: Panel
Window 1 scrollbar Slider
2
1 1 title
1 Header
body
1 Panel
65
Generalization Shape Separate Target Style
Polygon
Ellipse
Spline
...
Shape
Polygon
Ellipse
Shared Target Style
Spline
...
66
Generalization Vehicle venue
power power
{overlapping} WindPowered Vehicle
Truck
venue
MotorPowered Vehicle
{overlapping} Land Vehicle
Water Vehicle
Sailboat
67
Dependencies ClassA
ClassD
ClassB
«friend»
«friend»
operationZ()
«instantiate »
«call»
ClassC
«refine»
ClassD
ClassC combines two logical classes
ClassE
68
UML Views • User model view • Structural model view • Behavioral model view – Sequence Diagrams – StateCharts
• Implementation model view • Environment model view 69
Sequence Diagrams • Used to capture Scenarios (Use cases) • Step-by-step sequence of messages exchanges among objects. • Map directly to use cases – Used to realize a use case
70
71
StateCharts • Each class must be associated with a statechart that describes its behavior. • Sequence diagrams show behavior of objects and how they collaborate to achieve the goal at hand (Inter-Object). • Statecharts show the behavior of an object (IntraObject) • Invented by David Harel and adopted by UML as the Intra-object behavioral language. 72
Object Behavior - Object Life Cycle Can be captured by Statecharts
Initialize Initialize Object Object Wait Waitfor for Request Request Handle Handle Request Request
Terminate Terminate Object Object stop
73
Statecharts • Statechart is a behavioral language for the specification of real-time, event driven, and reactive systems. – states – events – actions – Transitions
FULL Put [noOFitems=MAX] / print(”writing”)
PARTIAL Event [Condition] / Action
74
Statecharts • Statecharts describe both: – how objects communicate (collaborate) and – how they Cary out their own internal behavior
• Statecharts states : – Basic state, Or-state, And-state
• Orthogonal regions (dashed line) – Idle for modeling concurrency. – interactions between regions typically through: • Message Broadcasting / Propagating • shared variables • awareness of other regions state changes “ the IN() Operator”.
75
Concurrency in UML S
T3
B
A T2
T3
T1
E
C T3
D
T
76
Concurrency in UML S
T3
B
A T2
T2
T1
E
C T3
D
T
77
Automata • A machine whose output behavior is not only a direct consequence of the current input, but of some past history of its inputs • Characterized by an internal state which represents this past experience ON ON ON ON
OFF OFF
78
State Machine (Automaton) Diagram on
• Graphical rendering of automata behavior Lamp On on off off Lamp Off 79
Outputs and Actions • As the automaton changes state it can on Lamp On Lamp outputs: generate print(”on”)
On
on
on/print(”on”) off
off Lamp Off
on
off
Mealy automaton
Lamp Off
off
Moore automaton 80
Basic UML Statechart Diagram “top” “top” state state Initial Initial pseudostate pseudostate
State State
top
Trigger Trigger
Ready Transition Transition
stop /ctr := 0 Final Final state state
Done Action Action
stop
81
What Kind of Behavior? • In general, state machines are suitable for describing event-driven, discrete behavior – inappropriate for modeling continuous behavior
threshold
time 82
Object Behavior - General Model Handling Handling depends depends on on specific specific request request type type
• Simple server model:
Initialize Initialize Object Object Wait Waitfor for Request Request
void:offHook (); {busy = true; obj.reqDialtone(); … };
Handle Handle Request Request
Terminate Terminate Object Object 83
Object Behavior and State Machines on
Initialize • Direct mapping: Object
Lamp On
Wait for Event Handle Event
on/print(”on”) off Lamp Off
Terminate Object
off
stop 84
Object and Threads •Passive objects: depend on external power (thread of execution) •Active objects: self-powered (own thread of execution) Initialize Initialize Object Object
Initialize Initialize Object Object
Wait Waitfor for Request Request
Wait Waitfor for Request Request
Handle Handle Request Request
Handle Handle Request Request
Terminate Terminate Object Object
Terminate Terminate Object Object 85
Passive Objects: Dynamic Semantics Initialize Initialize Object Object Wait Waitfor for Request Request Handle Handle Request Request
Terminate Terminate Object Object
•Encapsulation does not protect the object from concurrency conflicts! •Explicit synchronization is still required 86
Active Objects and State Machines • Objects that encapsulate own thread of execution anActiveObject #currentEvent : Eventpoll/defer created start
+ start ( ) + poll ( ) + stop ( )
start/^master.ready()
ready
ready stop/
poll/^master.ack()
87
Active Objects: Dynamic Semantics ActiveObject:
Run-to-completion model: •serialized event handling •eliminates internal concurrency •minimal context switching overhead 88
UML Views • • • •
User model view Structural model view Behavioral model view Implementation model view – Component Diagram
• Environment model view – Deployment Diagram 89
The Implementation View • Describes the structural and behavioral aspects of the implementation. • Diagrams: Component Diagram – Component diagrams - shows the implementation view of the system. It shows the organization and dependencies between actual components. – This is where the detail design is done. Pseudocode may be used. – Examples of things shown: • Call relationships are shown. • Link dependencies are shown. 90
The Environment View • Shows the actual hardware that is required to implement the solution. • Diagram: Deployment Diagram – Shows the environment of the system. Its shows the configuration and how the software components are mapped to it.
91
Exam Review
92
Q1 • a): Use Prototype for the Video Store software • b): Use Waterfall Model for the credit card software
93
Q2) Incremental Model Analysis
Design
Analysis
Code
Design
Analysis Analysis
Test Code
Design Design
Test
Code Code
Test Test
• When staffing is not available by deadline. 94
Q2) Incremental Model • It combines characteristics of the Waterfall model and the iterative nature of the Prototyping model. • 1st build is usually the CORE product • Each increment “Deliverable” may add a new functionality. • This is repeated until the product is complete • Go to page 35 for Figure
95
Q3) Requirement Elicitation • Ask the Customer what the system should do. – Objectives? – What is to be Accomplished? – How the system will satisfy the needs of the business? – How the system will be used? 96
Q4) • Behavioral Model – Depict Impact of events – STD
• Functional Model – How data is trasnformed – DFD
• Data Model – Define data objects, attributes and relationships – ERD 97
Q5)Three Generic team organizations 1.
Democratic Decentralized (DD) – – – –
2.
No Leader Task Coordinators be appointed for short duration Group made decisions Communication is Horizontal
Controlled Decentralized (CD) – – – –
Defined leader and secondary leader (subtasks) Problem solving remains a group activity Implementation is partitioned Communication is Horizontal 98
Three Generic team organizations •
Controlled Centralized (CC) – –
Top-level problem solving and team leader Vertical Communication
99
How to Decide team structure to use? •
Things to Consider: 1. How Difficult is the problem
CC Simple
CD
DD Complex 100
How to Decide team structure to use? •
Things to Consider: 2. Size of the Project
CC Large
CD
DD Small 101
How to Decide team structure to use? •
Things to Consider: 3. Time team will stay together
CC Short
CD
DD Long 102
How to Decide team structure to use? •
Things to Consider: 4. The degree to which a problem can be modularized
CC High
DD
CD Low
103
How to Decide team structure to use? •
Things to Consider: 5. Quality and Reliability of SW to be built
CC High
CD
DD Low 104
How to Decide team structure to use? •
Things to Consider: 6. How Firm is the Due Date
CC Less Time
CD
DD More Time 105
How to Decide team structure to use? •
Things to Consider: 7. Communication Required for the Project
CC Low
CD
DD High 106
Q6) Project Parameters • Five constraints that must remain in balance: – – – – –
Scope Quality Cost Time Resources 107
Q6) Design Models • Data Design – Transform the information domain (created in analysis) into Data structures.
• Architectural Design: – Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal
• Interfaces Design - How the system interfaces: – With itself (procedure calls) – With other systems – With users (Screens)
• Components Design – Structural elements into procedural description 108
Q7(A) Cohesion • Each module should have a central theme or purpose. – Should be able to describe a cohesive module using a sentence with one subject and one verb
• High cohesion is good. Low cohesion is to be avoided.
109
Q7(a) Coupling • Refers to the degree of interconnectedness between modules • Minimize coupling to reduce the ripple effect when changes are made. • The goal is to reduce connection paths between modules. • High coupling limits reuse. • lowest possible coupling 110
Q7(b)Coupling Types • Stamp coupling (low):
111
Process Maturity Levels • Level 1: Initial – Ad hoc, fewer processes are defined.
• Level 2: Repeatable – Level 1 + – Basic PjM processes to track Cost, Schedule and Functionality.
• Level 3: Defined – Level 2 + – Documented and standardized and integrated into an org wide SW process for all development and maintenance activities 112
Q8)CMM and KPA • Five point grading scheme that determines compliance with CMM which defines key activities required at each level.
113
Key Process Areas • Each Maturity Level is associated with KPAs. • KPAs describe those SW engineering functions that must present to satisfy a maturity level. • Each KPA is described by identifying: – Goals, Commitments, Abilities, Activities, and Methods for Monitoring and Verifying Implementation.
• 18 KPAs are defined across maturity model and mapped into different levels of the process maturity (Book page 25, 26). 114
Go to Design Document Template
115
Homework #2 • Q#1: 50 Points) Sketch the following OO diagrams for the class Project (Feature Tracking SW): – Use Cases as discussed in class (Complete) – Class Diagram showing Estimates, Features, Managers as objects – Sequence diagrams for at least 3 use cases from (a) – Describe the behavior of the Feature Class using Statechart. 116
Homework #2 • Q#2: 50 Points) – (a) Explain the object life cycle as shown in the figure below (25 Points). – (b) How does the object life cycle related or can be captured by a statechart? (25 Points)
117
Object Life Cycle Initialize Initialize Object Object
Wait Wait for Waitfor for Request Request Request
Handle Handle Request Request
Terminate Terminate Object Object 118
