cs48711-1/31 illinois institute of technology cs487 software engineering ooa with uml david lash
TRANSCRIPT
CS48711-1/31
Illinois Institute of Technology
CS487
Software Engineering
OOA with UML
David Lash
CS48711-2/31
UML: An Overview Unified Modeling Language
– An out growth of OMT - Object Modeling Technique– OO Software Engineering
UML is a modeling 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 a system to derive or evolve a system.
CS48711-3/31
UML: An Overview
The UML is not:
A visual programming language, but a visual modeling language.
A tool or repository specification, but a modeling language specification.
A process, but enables processes.
Fundamentally, the UML is concerned with capturing, communicating, and levering knowledge
CS48711-4/31
UML: An Overview UML applies to a multitude of different types of
systems, domains, and methods or processes. It is
– A general-purpose modeling language - focuses on acquiring, sharing, and utilizing knowledge coupled with extensibility mechanisms.
Broadly applicable modeling language - applicable to different types of systems, domains, and methods or processes.
Tool-supported modeling language - tools are available to support the application of the language to specify, visualize, construct, and document systems.
Industry-standardized modeling language, - not a proprietary and closed language but an open and fully extensible industry-recognized language.
CS48711-5/31
UML: Views
Unified Modeling Language supports 5 views to use diagrams to describe the system from different perspectives
– User Model View - Use-case modeling approach to representation of the end-user’s perspective.
– Structured Model View - Data and functionality viewed from inside the system (classes, objects & relationships)
– Behavior View - models the behaviours and interactions of various structures
– Implementation model view - the structural and behavior aspects o f the system
– Environment Model View - structural and behaviour aspects of the environment
CS48711-6/31
UML: Views
Unified Modeling Language supports 5 views to use diagrams to describe the system from different perspectives
– User Model View - Use-case modeling approach to representation of the end-user’s perspective.
– Structured Model View - Data and functionality viewed from inside the system (classes, objects & relationships)
– Behavior View - models the behaviours and interactions of various structures
– Implementation model view - the structural and behavior aspects of the system
– Environment Model View - structural and behaviour aspects of the environment
CS48711-7/31
UML: Uses a variety of Diagrams
Use Case
– Show a set of use cases and actors and their relationships
Actors: entities that interact with the system
Class– Show a set of classes, interfaces and
collaborations and their relationships
CS48711-8/31
UML: Diagrams
Interaction – Sequence and collaboration– Show an interaction, consisting of a set of
objects and their relationships
Dependency– A relationship between two elements in which
a change to one element may affect or supply information needed by the other element.
CS48711-9/31
UML: Diagrams State
– Shows behavior a class or use case.– Different notation
Activity – Show the flow from activity to activity within
a system
CS48711-10/31
UML: Diagrams
Component– Show the organizations and dependencies
among a set of components (subsystem)
Deployment– Show the configuration of run-time processing
nodes and components that live on them
CS48711-11/31
The OOA process
Use-cases CRC modeling (Class-Responsibility-
Collaborator modeling) - class definition & definiing hierarchies
Object-relationship modeling - ERD like Object Behaviour modeling
– state representations, event flow– event trace
CS48711-12/31
UML: Diagrams - Use Case
Description– A diagram that shows a set of use cases and
actors and their relationships Use Case - purpose
– Defines functional & operational requirements of the system
– Clear & unambiguous description of how the end-user & system interact (system’s context)
– provide basis for validation testing
Introduced by Ivar Jacobson - Replace Data Flow Diagram used in OMT
CS48711-13/31
Use Case: Terms Terms
– Actor An abstraction for entities outside a
system, subsystem, or class that interact directly with the system.
– Classifier A model element that describes
behavioral and structural features– Use Case
The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors.
CS48711-14/31
UML: Diagrams
Use Case
– Show a set of use cases and actors and their relationships
Actors: entities that interact with the system
Example: Consider homesafe with actors:– homeowner, sensors, & monitoring &
response subsystem– Look only at homeowner for now
CS48711-15/31
Use Case: Actor Relationships
Salesperson
Sales Manager Sales Clerk
CS48711-16/31
Use Case HL Diagram - I
Configures
Interacts
CS48711-17/31
Use Case HL Diagram - IIThe Interacts Function
Inputs Passwords
Inquirezone
status
PressPanic Button
Activates/deactivates
system
ValidatesPassword
Uses
QuerySensor
Uses
Uses
CS48711-18/31
Use Case: Symbols
Actor
system boundary
Use Case
generalizationextend / includeCommunication
CS48711-19/31
Use Case: Relationship
Place Order
ArrangePayment
RequestCatalog
<<extend>>(more requests)
Cash Credit
<<include>>
CS48711-20/31
Use Case Example
Customer
Supervisor
Shipping Clerk
Salesperson
Telephone Catalog
checkstatus
placeorders
fill orders
establishcredit
CS48711-21/31
Hints and Tips
A well-structured Use Case diagram:– Focus on communicating one aspect of a
system’s static Use Case view– Contain only those use cases and actors that
are essential to understanding that aspect– Provide detail consistent with its level of
abstraction; you expose only those adornments that are essential to understanding
– Is not so minimalist as to misinform the reader about the semantics that are important
CS48711-22/31
Hints and Tips
When you draw a Use Case diagram– Give it a name that communicates its purpose– Lay out its elements to minimize lines that
cross– Organize its elements spatially so that
behaviors and roles that are semantically close are laid out physically close
– Use notes and color as visual cues to draw attention to important features of your diagram
– Try not to show too many kinds of relationships
CS48711-23/31
The OOA process
Use-cases CRC modeling (Class-Responsibility-
Collaborator modeling) - class definition & definiing hierarchies
– Object-relationship modeling - ERD like
Object Behavior modeling– state representations, event flow– event trace
CS48711-24/31
CRC modeling (Class-Responsibility-Collaborator
modeling) - class definition & defining hierarchies
A simple means for identifying and organizing classes
CS48711-25/31
Selecting Objects (review)
Already spoke about the Six characteristics that should be used on each potential object:
– Retained Information - information about it must be remembered
– Needed services - have a set of identifiable operations that can change attribute’s value
– Multiple Attributes - Are the attributes “major” and useful?
– Common Attributes - can define a set that apply to all occurrences of object
– Essential requirements - External entity in problem and produces information essential to solution
CS48711-26/31
Collaborations- Defining relatips between Classes
A Class can :– use its operations to manipulate its own attributes
or – collaborate with other classes if it cannot complete
its responsibilities by itself Review classes & determine relationship type:
– is-part-of relationship - All classes part of an aggregate class. Player_body is part of player, player_arms is part of player.
– has-knowledge-of relationship - when 1 class must acquire information from another. Control_panel object must determine if any sensors are open. determine_sensor_status relationship between them. Control_panel must work with sensor to get status.
– depends-upon relationship - 2 classes have a dependency that is not 1 of the 2 above -Player_head must always be connected to player-body. (yet they can exist w/o knowledge of eachother).
CS48711-27/31
UML: Create Class Diagram
Use the Class diagram to – Show a set of classes, interfaces and
collaborations and their relationships– Focuses on the the structure of the classes &
hierarchies
Components– Name– Attributes– Operations– Responsibilities
CS48711-28/31
UML: Class Symbol
origin
move()resize()display()
Shape
Nam e
Operations
Attributes
CS48711-29/31
UML: Class Diagram Chart Structure
Sensor
Attributes
Operatations
Entry Sensor Smoke Sensor Monitor Sensor
•After ID classes & objects, => determine structure. - Objects might be generalization/specialization structure. - Sensor is the generalization of the specialized entry, smoke & motion sensors
CS48711-30/31
UML: Class Diagram - Showing Relationships
- The object might be composed of a number of objects- The diamond implies an assembly relationship of the
composite aggregate.
CS48711-31/31
UML: Class Diagram
Relationships
– Dependency A relationship that states that a change
in specification of one thing may affect another thing that uses it, but not necessarily the reverse
– Generalization (Inheritance) A relationship between a general thing
(parent, super-class) and a more specific kind of that thing
CS48711-32/31
UML: Class Diagram
Relationships– Association
A structural relationship that specifies that objects of one thing are connected to objects of another
Characteristics– Name– Role– Multiplicity
– Aggregation Components that comprise the owning
object
CS48711-33/31
UML: Class Relationships
open()close()m ove()display()handleEvent()
W indow
C onsoleW indow D ialogBox C ontro l
Event
dependency
association
generalization
CS48711-34/31
UML: Class Association
Person CompanyW orks For >
name name direction
association
CS48711-35/31
UML: Class Association
Person Company
association
employee employer
role name
CS48711-36/31
UML: Class Association
Person Company
association
employee employer
multiplicity
1..* *
Indicates many
CS48711-37/31
UML: More On Cardinality
CS48711-38/31
UML: Class Aggregation
Department
Company
whole
part
1
*
aggregation(solid indicates composition)
Evaluate cardinality it can be: 0 to 1, 1 to 1, 0 to many, 1 to many.
CS48711-39/31
Identifying Classes
Develop an automated student registration system. The students registration system identify the School (i.e. Arts & Sciences, Engineering, Fine Arts, etc.) in which the student is registered. It also shall Identify the current classes offered by each department and the instructor for each class.
CS48711-40/31
UML: Class Diagram Example
nameaddress...
addstudent()removestudent()...
School
namestudentID
Student
1..*
*
Graduate UnderGraduate
name
Department
description
Course
name
Instructor
Offers
1
1..*
Attends >
< Teaches
has
1..*1
* * 1..3 1
Assigned To ^
Chair1
0..1
0..1Schedule
accepted
CS48711-41/31
The OOA process
Use-cases CRC modeling (Class-Responsibility-
Collaborator modeling) - class definition & definiing hierarchies
– Object-relationship modeling - ERD like
Object Behavior modeling– state representations, event flow– event trace
CS48711-42/31
State Transitions
Within OO systems look at state that are:– state of each object as system performs its
function– State of system as observable from the outside world (as
system works)
Types– Active State transition diagram -
passive state => the current status of all attributes. E.g., video_game_player might have position, orientation
active state => the status of the object as it undergoes a transformation, moving, at rest, injured, being cured.
Action occurs concurrently with the state transition
CS48711-43/31
UML: Activity Diagram
CS48711-44/31
State Transitions
Within OO systems look at state that are:– state of each object as system performs its
function
– State of system as observable from the outside world (as system works)
Types– Event trace model -
how events cause transitions from object to object
key objects only– Event flow model
CS48711-45/31
UML: Interaction Diagram
CS48711-46/31
State Transitions
Within OO systems look at state that are:– state of each object as system performs its function
– State of system as observable from the outside world (as system works)
Types– Event trace model (ETM) -
how events cause transitions from object to object key objects only
– Event flow model - After ETM, collect events causing transitions between
objects collated into inputs & outputs from object(s) All events that flow into & out of object shown Once done can do more detailed state diagram
CS48711-47/31
Partial Event Flow Diagram
Homeowner
ControlPanel
System
SystemReady
SelectsStay/aw
ay.Enters Passw
d
Rdy for next
action. Rdy for
activation/deactivation
Beep sounded.sensors
activated/deactivated.R
ed light on.
Initiates beep.Activate/
deactivatesensors