SE 430 Object Oriented Modeling

1. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 SE 430: Lecture 5

2. Administrivia • Comments and Feedback • Announcements • Assignment schedule – assignment 4 due October 20, 2016. • Midterm Examination this weekend [October 8-12] • Will use the Desire2Learn System (https://d2l.depaul.edu/) • Using Desire2Learn [See note]. • Details • Things to avoid SE 430: Lecture 5

3. Discussion: Assignment 2 • Eight use cases [in descending order of priority]: • Display exhibit information. • Content Authoring. • Browse list of exhibits. • Track virtual guide usage. • Museum visitor requests guidance to a specific location in the museum • Initialize VTG for visitor use • Display special events or custom tours • Suggest next exhibit or next stop on a tour SE 430: Lecture 5

4. Assignment 2 Comments • Need to clarify what is kept in ATS vs. what is kept in VIS. • Exhibit information is kept in VIS: History, biography, education information, relationships, etc. ATS just keeps basic details about artifact. Primarily for use of curators keeping track of artifacts. • Use cases for parts of the system that are not part of the VIS. • Lack of understanding of functions and responsibilities of each subsystem. • Wrong SSD: read instructions! • Non-actors. VIS is NOT an actor. VTG is NOT an actor. • Mention concepts such as database. • Using a “database” is too early to discuss. • Evidence of IS/IT thinking – everything is a database. • Some things cannot be put into a database: • Video and audio files; pictures; exhibit program details; textual files containing exhibit information SE 430: Lecture 5

5. Assignment 2 Comments • Glossary incomplete or weak; needs to be expanded; add use case names and descriptions; also actors. • A use case should satisfy a single goal or related goals. Do not consolidate several into one use case. No idea of what things are? • A use case diagram is NOT a class diagram. • A system sequence diagram is NOT a use case description. SE 430: Lecture 5

6. SE 430 – Class 5 Topics: • Transition to Design • Software Architecture • Overview of Software Architecture • Architectural Planning • Tools and Techniques for Transition to Design • Design Scenarios • The Human Computer Interface: Tiered Architecture • Robustness Analysis • Function-Class Decomposition Reading: • Arlow & Neustadt, Ch.'s 1, 8.4.3, 16, 19, [6-9 last week] • Reading list SE 430: Lecture 5

7. Thought for the Day The difference between theory and practice is that, in theory, there is no difference between theory and practice, but in practice, there is. SE 430: Lecture 5

8. Last Time • Domain Model • Introduction to Objects, Classes and their relationships • Object-Oriented Domain Modeling • Conceptual Model • How to build • CRC Cards • Example • Domain Modeling Artifacts • Conceptual Classes • Class Associations • Class Attributes • Class diagrams • System Glossary SE 430: Lecture 5

9. Big Picture SE 430: Lecture 5

10. UML Notation • You should be reading Arlow & Neustadt, Chapter 1 for details on UML notation. • Specifically, look at chapter 7 for class diagrams. SE 430: Lecture 5

11. Transition to Design SE 430: Lecture 5

12. What to do after analysis? How does one proceed from the domain model to a design model? • Design software architecture • Software architecture acts as a bridge between analysis and design. • Architecture provides a framework within which to perform object-level design. SE 430: Lecture 5

13. What to do after analysis? • Perform object-level design using various design tools and techniques • CRC cards [Discussed last week]. • Design scenarios and design patterns [Next lectures.] • Function-Class Decomposition (FCD) • Robustness Analysis • Capture design decisions in artifacts • Robustness Diagrams • Sequence and communication (collaboration) diagrams. [Next time.] • State charts [Next time.] • Design Class Diagrams. SE 430: Lecture 5

14. Software Architecture SE 430: Lecture 5

15. Overview of Software Architecture SE 430: Lecture 5

16. What is software architecture? • Software architecture captures decisions about: • The overall structure of the software system • The structural elements of the system, their interfaces, and their collaborations • The architectural style of the system, often defined by architectural patterns • Provides a common abstraction used for communication among system stakeholders Why is software architecture important? • Represents the earliest design decision for the system. • Because of the primacy of architecture in the design process, it carries a disproportionate amount of importance. • Represents a potentially reusable model for other systems with similar requirements. SE 430: Lecture 5

17. Choosing a candidate architecture • Choice of a candidate architecture involves several considerations: • Available development resources. • Development planning • Use of existing components • Future modifications • Meeting behavioral requirements • Satisfying dynamic, non-functional design aspects of the system, called quality attributes SE 430: Lecture 5

18. Essential quality attributes • Availability. Probability that the system will be operational when needed • Performance. Concerned with the responsiveness of the system to events or the number of events handled per unit time • Modifiability. Concerned with the cost of changes to the system • Security. Concerned with the ability of a system to defend against various attacks while continuing to provide service to legitimate users • Usability. Concerned with the interaction between the system and the user • Testability. Concerned with the ability of a system to expose its behavior (and hence its faults) during testing • It is possible to generate scenarios for all of these quality attributes SE 430: Lecture 5

19. Choosing a candidate architecture • Once a candidate architecture is identified, the most effective way of evaluating it is through scenario-based analysis • Scenarios are generated for all relevant quality attributes • Stakeholders provide the input to the scenarios: how they want the system to respond to various conditions SE 430: Lecture 5

20. Example: Mixed information display Note:the examples in class for the rest of the term may or may not relate to the Museum Automation Project. Do not assume they do. • System requirements • The system must be able to display multiple types of media within a single display page. • The system must be able to retrieve media content from different sources. • The system must be able to access alternate sources of media content if the primary source is unavailable or unable to complete the request. • The system will have access to distributed processing and a high-speed data connection. SE 430: Lecture 5

21. Simple schematic for problem SE 430: Lecture 5

22. Next … • Perform architectural planning: • Search for or develop architectural patterns relevant to the system. • Identify the initial internal release: the architectural baseline: a “small, skinny” executable system that encompasses most of the architecturally-significant components of the system. • Identify subsequent architectural releases that iteratively and incrementally build functionality upon the architectural baseline. • Throughout, identify constraints and enablers that will influence architecture, such as platforms, legacy systems, COTS components, supporting technologies. • Capture architectural decisions in the appropriate UML artifacts. SE 430: Lecture 5

23. Architectural Planning SE 430: Lecture 5

24. What is an architectural pattern? • Represents a structural organization plan for a software system. • Can be applied in various design contexts. • Consists of: • A set of predefined subsystems or components. • Subsystem or component responsibilities. • Rules and guidelines for structuring relationships or collaborations among the subsystems or components. • Also known as architectural style or system design pattern. SE 430: Lecture 5

25. Architectural pattern classifications Mud to Structure: Layers Pipes and Filters Blackboard Proxy Distributed Systems: Broker Interactive Systems: Model-View-Controller Presentation-Abstraction-Control Adaptable Systems: Reflection Microkernel • Most comprehensive reference on architectural patterns: • Pattern-Oriented Software Architecture: A System of Patterns, Buschmann et al., John Wiley & Sons (U.K.) 1996. ISBN 0-471-95869-7 We will discuss architectural patterns in more detail in lecture 9. SE 430: Lecture 5

26. Relevant patterns for our example • We will discuss architectural patterns in detail in lecture 9, for now we want to look at the two we need. • The mixed information display example readily decomposes into two major functional aspects: • Information display. • Information retrieval. • The information display aspect is a candidate for the Model-View-Controller architectural pattern. • Information retrieval aspect is a candidate for Broker architectural pattern. SE 430: Lecture 5

27. Model-View-Controller (MVC) • Divides an interactive application into three components: • Model contains core functionality and data model. • Views display information to user and accept user input. • Controllers receive input from views and modify state of model. • View can only modify model data via controller. Uses Observer to notify Controller of update. • View can only read data from model. Model uses Observer to notify View of update. UML icon for a component. Arrows show visibility (not data flow!) of one component to another. SE 430: Lecture 5

28. Model-View-Controller Static structure • Integral use of Observer pattern • Controller observes View • Controller acquires updates of View • Controller modifies Model • View observes Model • View acquires updates of Model • Note: • View does not modify Model • Use of two interface notations is redundant. For illustration purposes only SE 430: Lecture 5

29. Model-View-Controller Dynamic behavior SE 430: Lecture 5

30. Broker • The Broker architectural pattern decouples components that interact by remote service invocations • Broker component of the pattern is responsible for coordinating communication: • Forwarding requests • Returning results • Handling exceptions • Best-known examples are the Common Object Request Broker Architecture (CORBA) and Java RMI SE 430: Lecture 5

31. Broker schematic SE 430: Lecture 5

32. Broker component view Client-side proxy Client Broker Server-side proxy Server SE 430: Lecture 5

33. Broker component view SE 430: Lecture 5

34. Applying patterns to our problem Model-View-Controller Architecture Broker Architecture SE 430: Lecture 5

35. Identifying the architectural baseline • It is impossible to tackle all the architectural challenges of building the system at one time • Identify the architecturally-significant use cases, those that represent: • Mitigation of the most serious development risks • High importance to the users • Coverage of all important system functions • Identify the essential elements of the initial internal executable release, the architectural baseline, from among the set of architecturally-significant use-cases • The architectural baseline should implement the core high-risk functionality, ‘stubbing out’ the non-core, lower-risk functionality • Architectural baseline is not a prototype! It is the foundation for all future development SE 430: Lecture 5

36. Architecturally-significant use case Name: Display real-time data in graph. Actors: • User (primary) • Data directory service (supporting) • Real-time data server (supporting) Preconditions: • The system must be running. • The system must have network access to the supporting actors. Postconditions: The system will be ready to accept other commands from the user. SE 430: Lecture 5

37. Use case event flow • This use case begins when the user selects a real-time data menu item on the browser display. • The system displays a list of available graphical format types. • User selects a graphical format type. • User enters a real-time data update frequency. • User enters length of time to monitor data. • The system displays the requested data using the graphical format specified by the user. • The system refreshes the data at the frequency specified by the user. • System repeats steps 6 & 7 until the length of time to monitor the data expires. • This use case ends when the length of time to monitor the data has expired. SE 430: Lecture 5

38. Why choose this use case? • It is important to the user • It represents a critical function of the system, to display data in a format selected by the user. • It touches on all important functions • User interaction. • Data location and retrieval. • Data display. • It contains significant risk elements • User-specified data. • User-specified display format. • System needs to autonomously display data updates at a specified frequency for a specified duration. SE 430: Lecture 5

39. Identifying architectural releases • The architectural baseline is only the first of several architectural releases • Subsequent architectural releases identify slices through the architecture that each satisfy one or more use cases and are executable • Architectural releases explicitly address the iterative and incremental construction of the system • Releases represent thestable intermediates characteristic of organized complex systems • Planning process encompasses important behavior of all significant components and subsystems across the set of architectural releases • Architectural baseline and subsequent releases are prioritized based on functionality and risk factors SE 430: Lecture 5

40. Review: Risk factors • Requirements risks • Have you properly identified requirements for system? • Have you reviewed project scope, set functionality priorities? • Technological risks • Are you using a new, untested technology or depend on a third-party product (the latter also called dependency risk)? • Skills risks • Are you planning to do something with which you are completely unfamiliar? • Political risks • Is project showing sufficient progress to stakeholders? • Does project still possess a ‘champion’ in organization? SE 430: Lecture 5

41. Scheduling architectural releases Set of releases includes, with percent functionality: • Architectural baseline (~20%). • Several subsequent releases. • Alpha release (~80%). • Beta release (~100%, with bugs). • Final 1.0 release (100%, bug-free). Encompasses all requirements of the production system. Schedule is a formal development plan of architectural releases, team tasks, and risk assessments. SE 430: Lecture 5

42. Constraints and enablers • Identify and address factors external to the system that will affect the architecture of the system. • Address issues raised in Supplemental Requirements plus other logical and physical factors. • Examples: • System software: operating system(s) and DBMSs. • Middleware: object request brokers and application frameworks. • Legacy systems planned for use with the system. • Standards and policies. • Nonfunctional requirements such as availability, response times, etc. • Note: One person's constraint may be another person's enabler! SE 430: Lecture 5

43. Elements of our architectural baseline Provides only one type of data view. Legacy component. Controllers just implement Observer pattern. Has fixed or limited range of targets Decide to incorporate real-time update in later architectural release. Mostly data repository with minimal logic. Legacy component. Need nearly full implementation. SE 430: Lecture 5

44. Tools and Techniques for Transition to Design SE 430: Lecture 5

45. Design scenarios design scenarios are sequences of incremental steps leading towards introduction of desirable properties into a software architecture. SE 430: Lecture 5

46. Design scenarios • Select one or a small set of scenarios (primary and alternates) related to a single use case. • Mentally walk through the scenario activities, identifying software abstractions (classes or objects), assigning responsibilities and identifying collaborations. • Establish well-defined abstraction boundaries and responsibilities. • Concentrate on behavior only, not implementation. We will discuss design scenarios in detail later. SE 430: Lecture 5

47. Tiered Software Design SE 430: Lecture 5

48. Tiered Software Design Logical Architecture Design • Part of the Analysis & Design workflow. • Identify the macro-level logical partitioning into layers and subsystems. Software architecture tends to have layers of software • Called “Tiered Software Design” • Similar to the layering of Applications/Libraries/Operating Systems • We have an architectural pattern: layering SE 430: Lecture 5

49. Multi-Tier Layered Architectures Separate presentation and application logic, and other areas of concern. UI Layer “Domain” or “Application Logic” Layer ServicesLayer Persistence Subsystem Logging Subsystem . . . SE 430: Lecture 5

50. Tiered Software Design Tiered Software design – SE 430: Lecture 5