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 beused 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-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

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

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 (system’s 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 Uses Validates Password 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 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

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

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_bodyis part ofplayer, 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 toplayer-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, => 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 => 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

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