1 / 47

Illinois Institute of Technology

Illinois Institute of Technology. CS487 Software Engineering OOA with UML David Lash. UML: An Overview. Unified Modeling Language An out growth of OMT - Object Modeling Technique OO Software Engineering UML is a modeling language for

lance-kent
Download Presentation

Illinois Institute of Technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related