Illinois Institute of Technology

1
Illinois Institute of Technology

• CS487
• Software Engineering
• OOA with UML
• David Lash

2
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.

3
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

4
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.

5
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-users 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

6
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-users 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

7
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

8
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.

9
UML Diagrams

• State
• Shows behavior a class or use case.
• Different notation
• Activity
• Show the flow from activity to activity within a
  system

10
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

11
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

12
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 (systems context)
• provide basis for validation testing
• Introduced by Ivar Jacobson - Replace Data Flow
  Diagram used in OMT

13
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.

14
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

15
Use Case Actor Relationships
16
Use Case HL Diagram - I
Interacts
Configures
17
Use Case HL Diagram - IIThe Interacts Function
Inputs Passwords
Validates Password
Uses
Uses
Inquire zone status
Query Sensor
Uses
Press Panic Button
Activates/ deactivates system
18
Use Case Symbols
19
Use Case Relationship
20
Use Case Example
21
Hints and Tips

• A well-structured Use Case diagram
• Focus on communicating one aspect of a systems
  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

22
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

23
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

24
CRC modeling (Class-Responsibility-Collaborator
modeling) - class definition defining
hierarchies

• A simple means for identifying and organizing
  classes

25
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 attributes 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

26
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).

27
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

28
UML Class Symbol
29
UML Class Diagram Chart Structure

• After ID classes objects, gt determine
  structure. - Objects might be
  generalization/specialization structure.
  - Sensor is the generalization of the
  specialized entry, smoke motion sensors

30
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.
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

32
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

33
UML Class Relationships
34
UML Class Association
35
UML Class Association
36
UML Class Association
Indicates many
37
UML More On Cardinality
38
UML Class Aggregation
Evaluate cardinality it can be 0 to 1, 1 to 1, 0
to many, 1 to many.
39
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.

40
UML Class Diagram Example
41
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

42
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 gt the current status of all
  attributes. E.g., video_game_player might have
  position, orientation
• active state gt the status of the object as it
  undergoes a transformation, moving, at rest,
  injured, being cured.
• Action occurs concurrently with the state
  transition

43
UML Activity Diagram
44
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

45
UML Interaction Diagram
46
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

47
Partial Event Flow Diagram