CS /31 Illinois Institute of Technology CS487 Software Engineering OOA with UML David Lash

CS /31 UML: An Overview u Unified Modeling Language – An out growth of OMT - Object Modeling Technique – OO Software Engineering u 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 u the artifacts of a system to derive or evolve a system.

CS /31 UML: An Overview u 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. u Fundamentally, the UML is concerned with capturing, communicating, and levering knowledge

CS /31 UML: An Overview u 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.

CS /31 UML: Views u 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

CS /31 UML: Views u 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

CS /31 UML: Uses a variety of Diagrams u Use Case – Show a set of use cases and actors and their relationships u Actors: entities that interact with the system u Class – Show a set of classes, interfaces and collaborations and their relationships

CS /31 UML: Diagrams u Interaction – Sequence and collaboration – Show an interaction, consisting of a set of objects and their relationships u Dependency – A relationship between two elements in which a change to one element may affect or supply information needed by the other element.

CS /31 UML: Diagrams u State – Shows behavior a class or use case. – Different notation u Activity – Show the flow from activity to activity within a system

CS /31 UML: Diagrams u Component – Show the organizations and dependencies among a set of components (subsystem) u Deployment – Show the configuration of run-time processing nodes and components that live on them

CS /31 The OOA process u Use-cases u CRC modeling (Class-Responsibility- Collaborator modeling) - class definition & definiing hierarchies u Object-relationship modeling - ERD like u Object Behaviour modeling – state representations, event flow – event trace

CS /31 UML: Diagrams - Use Case u Description – A diagram that shows a set of use cases and actors and their relationships u 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 u Introduced by Ivar Jacobson - Replace Data Flow Diagram used in OMT

CS /31 Use Case: Terms u Terms – Actor u An abstraction for entities outside a system, subsystem, or class that interact directly with the system. – Classifier u A model element that describes behavioral and structural features – Use Case u 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.

CS /31 UML: Diagrams u Use Case – Show a set of use cases and actors and their relationships u Actors: entities that interact with the system u Example: Consider homesafe with actors: – homeowner, sensors, & monitoring & response subsystem – Look only at homeowner for now

CS /31 Use Case: Actor Relationships

CS /31 Use Case HL Diagram - I Configures Interacts

CS /31 Use Case HL Diagram - II The Interacts Function Inputs Passwords Inquire zone status Press Panic Button Activates/ deactivates system Validates Password Uses Query Sensor Uses

CS /31 Use Case: Symbols

CS /31 Use Case: Relationship

CS /31 Use Case Example

CS /31 Hints and Tips u 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

CS /31 Hints and Tips u 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

CS /31 The OOA process u Use-cases u CRC modeling (Class-Responsibility- Collaborator modeling) - class definition & definiing hierarchies – Object-relationship modeling - ERD like u Object Behavior modeling – state representations, event flow – event trace

CS /31 CRC modeling (Class- Responsibility-Collaborator modeling) - class definition & defining hierarchies u A simple means for identifying and organizing classes

CS /31 Selecting Objects (review) u 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

CS /31 Collaborations- Defining relatips between Classes u A Class can : – use its operations to manipulate its own attributes or – collaborate with other classes if it cannot complete its responsibilities by itself u 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).

CS /31 UML: Create Class Diagram u 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 u Components – Name – Attributes – Operations – Responsibilities

CS /31 UML: Class Symbol

CS /31 UML: Class Diagram Chart Structure After ID classes & objects, => determine structure. - Objects might be generalization/specialization structure. - Sensor is the generalization of the specialized entry, smoke & motion sensors

CS /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.

CS /31 UML: Class Diagram u Relationships – Dependency u 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) u A relationship between a general thing (parent, super-class) and a more specific kind of that thing

CS /31 UML: Class Diagram u Relationships – Association u A structural relationship that specifies that objects of one thing are connected to objects of another u Characteristics – Name – Role – Multiplicity – Aggregation u Components that comprise the owning object

CS /31 UML: Class Relationships

CS /31 UML: Class Association

CS /31 UML: Class Association

CS /31 UML: Class Association Indicates many

CS /31 UML: More On Cardinality

CS /31 UML: Class Aggregation Evaluate cardinality it can be: 0 to 1, 1 to 1, 0 to many, 1 to many.

CS /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.

CS /31 UML: Class Diagram Example

CS /31 The OOA process u Use-cases u CRC modeling (Class-Responsibility- Collaborator modeling) - class definition & definiing hierarchies – Object-relationship modeling - ERD like u Object Behavior modeling – state representations, event flow – event trace

CS /31 State Transitions u 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) u Types – Active State transition diagram - u passive state => the current status of all attributes. E.g., video_game_player might have position, orientation u active state => the status of the object as it undergoes a transformation, moving, at rest, injured, being cured. u Action occurs concurrently with the state transition

CS /31 UML: Activity Diagram

CS /31 State Transitions u 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) u Types – Event trace model - u how events cause transitions from object to object u key objects only – Event flow model

CS /31 UML: Interaction Diagram

CS /31 State Transitions u 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) u Types – Event trace model (ETM) - u how events cause transitions from object to object u key objects only – Event flow model - u After ETM, collect events causing transitions between objects collated into inputs & outputs from object(s) u All events that flow into & out of object shown u Once done can do more detailed state diagram

CS /31 Partial Event Flow Diagram