SE 430 Object Oriented Modeling Dennis Mumaugh Instructor
SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm. depaul. edu Office: CDM, Room 428 Office Hours: Thursday, 4: 00 – 5: 30 October 6, 2016 SE 430: Lecture 5 1 of 91
Administrivia § Comments and Feedback § Announcements Ø Assignment schedule – assignment 4 due October 20, 2016. § Midterm Examination this weekend [October 8 -12] Ø Ø Will use the Desire 2 Learn System (https: //d 2 l. depaul. edu/) Using Desire 2 Learn [See note]. » Details » Things to avoid October 6, 2016 SE 430: Lecture 5 2 of 91
Discussion: Assignment 2 § Eight use cases [in descending order of priority]: 1. Display exhibit information. 2. 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 3. 4. 5. 6. 7. 8. October 6, 2016 SE 430: Lecture 5 3 of 91
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 Ø § § October 6, 2016 SE 430: Lecture 5 4 of 91
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. October 6, 2016 SE 430: Lecture 5 5 of 91
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 October 6, 2016 SE 430: Lecture 5 6 of 91
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. October 6, 2016 SE 430: Lecture 5 7 of 91
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 October 6, 2016 SE 430: Lecture 5 8 of 91
Big Picture October 6, 2016 SE 430: Lecture 5 9 of 91
UML Notation § You should be reading Arlow & Neustadt, Chapter 1 for details on UML notation. Ø Specifically, look at chapter 7 for class diagrams. October 6, 2016 SE 430: Lecture 5 10 of 91
Transition to Design October 6, 2016 SE 430: Lecture 5 11 of 91
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 objectlevel design. October 6, 2016 SE 430: Lecture 5 12 of 91
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. October 6, 2016 SE 430: Lecture 5 13 of 91
Software Architecture October 6, 2016 SE 430: Lecture 5 14 of 91
Overview of Software Architecture October 6, 2016 SE 430: Lecture 5 15 of 91
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. Ø October 6, 2016 SE 430: Lecture 5 16 of 91
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 October 6, 2016 SE 430: Lecture 5 17 of 91
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 October 6, 2016 SE 430: Lecture 5 18 of 91
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 October 6, 2016 SE 430: Lecture 5 19 of 91
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 highspeed data connection. October 6, 2016 SE 430: Lecture 5 20 of 91
Simple schematic for problem October 6, 2016 SE 430: Lecture 5 21 of 91
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. October 6, 2016 SE 430: Lecture 5 22 of 91
Architectural Planning October 6, 2016 SE 430: Lecture 5 23 of 91
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. October 6, 2016 SE 430: Lecture 5 24 of 91
Architectural pattern classifications § 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 -47195869 -7 § Mud to Structure: Ø Ø Layers Pipes and Filters Blackboard Proxy § Distributed Systems: Ø Broker § Interactive Systems: Ø Ø Model-View-Controller Presentation-Abstraction. Control § Adaptable Systems: Ø Ø Reflection Microkernel We will discuss architectural patterns in more detail in lecture 9. October 6, 2016 SE 430: Lecture 5 25 of 91
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. October 6, 2016 SE 430: Lecture 5 26 of 91
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. October 6, 2016 SE 430: Lecture 5 UML icon for a component. Arrows show visibility (not data flow!) of one component to another. 27 of 91
Model-View-Controller Static structure § Integral use of Observer pattern § Controller observes View § Controller acquires updates of § § October 6, 2016 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 28 of 91
Model-View-Controller Dynamic behavior October 6, 2016 SE 430: Lecture 5 29 of 91
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 October 6, 2016 SE 430: Lecture 5 30 of 91
Broker schematic October 6, 2016 SE 430: Lecture 5 31 of 91
Broker component view Client Server Broker Client-side proxy October 6, 2016 Server-side proxy SE 430: Lecture 5 32 of 91
Broker component view October 6, 2016 SE 430: Lecture 5 33 of 91
Applying patterns to our problem Model-View. Controller Architecture October 6, 2016 Broker Architecture SE 430: Lecture 5 34 of 91
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 architecturallysignificant 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 October 6, 2016 SE 430: Lecture 5 35 of 91
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. October 6, 2016 SE 430: Lecture 5 36 of 91
Use case event flow 1. This use case begins when the user selects a real-time data menu 2. 3. 4. 5. 6. 7. 8. 9. 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. October 6, 2016 SE 430: Lecture 5 37 of 91
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. October 6, 2016 SE 430: Lecture 5 38 of 91
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 the stable 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 October 6, 2016 SE 430: Lecture 5 39 of 91
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 thirdparty 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? October 6, 2016 SE 430: Lecture 5 40 of 91
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%, bugfree). Encompasses all requirements of the production system. Schedule is a formal development plan of architectural releases, team tasks, and risk assessments. October 6, 2016 SE 430: Lecture 5 41 of 91
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! October 6, 2016 SE 430: Lecture 5 42 of 91
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 Mostly data repository with minimal logic. October 6, 2016 Need nearly full implementation. SE 430: Lecture 5 Decide to incorporate real-time update in later architectural release. Legacy component. 43 of 91
Tools and Techniques for Transition to Design October 6, 2016 SE 430: Lecture 5 44 of 91
Design scenarios design scenarios are sequences of incremental steps leading towards introduction of desirable properties into a software architecture. October 6, 2016 SE 430: Lecture 5 45 of 91
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. October 6, 2016 SE 430: Lecture 5 46 of 91
Tiered Software Design October 6, 2016 SE 430: Lecture 5 47 of 91
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 October 6, 2016 SE 430: Lecture 5 48 of 91
Multi-Tier Layered Architectures Separate presentation and application logic, and other areas of concern. UI Layer “Domain” or “Application Logic” Layer Services Layer Persistence Subsystem October 6, 2016 Logging Subsystem SE 430: Lecture 5 . . . 49 of 91
Tiered Software Design Tiered Software design – Architectural Layers Three-tier design Presentation Graphical interface Application Logic q Domain Objects q Service Objects q Domain objects fulfill application requirements q Service objects provide supporting services (database interface, report generator, etc. ) Storage Persistent storage mechanism October 6, 2016 SE 430: Lecture 5 50 of 91
Tiered Software Design § Three-tier design – § The Presentation tier is relatively free of application processing. § The middle tier communicates with the back-end storage layer. § Gang of Four pattern: Model-View-Controller October 6, 2016 SE 430: Lecture 5 51 of 91
Classic 3 Tier Architecture What happens when we press this? October 6, 2016 SE 430: Lecture 5 52 of 91
Classic 3 Tier Architecture October 6, 2016 SE 430: Lecture 5 53 of 91
Controller class A system event is an external input event associated with a system operation A Controller class is created to handle system events. § The Controller class can represent one of the following: Ø Façade controller » The overall “system” » The overall business or organization Ø Role controller » A real-world role active in the task Ø Use case controller also known as “<Use. Case. Name>Handler” » Handles all system events of a use case • Maintains the state of the use case • Recognizes out of sequence system events October 6, 2016 SE 430: Lecture 5 54 of 91
Controller class Advantages of controllers § A separation of concerns. Domain objects handle domain process, not the presentation layer. § The controller class becomes a place to capture information about the state of the use case. Design problem with Façades and Role Controller § A tendency to lose cohesion by doing too much unrelated work. § If controllers lose cohesion, factor it into smaller controllers. October 6, 2016 SE 430: Lecture 5 55 of 91
Controller class Minimize controller designs where a few objects do most of the work. Beware of: § “dumb” objects – objects that only provide get. Attribute() or set. Attribute() access. § “super controllers” – objects that ask for an object's state, perform calculations, and do most of the work. Distribute work to all objects. § Objects should do the work, based on the information they contain (data and links to other objects). October 6, 2016 SE 430: Lecture 5 56 of 91
Robustness Analysis Robustness analysis sits right in the gap between what the system has to do and how it's actually going to accomplish this task. October 6, 2016 SE 430: Lecture 5 57 of 91
Transition to Detailed Design: Roadmap Documents included in this milestone: Ø Ø Examples of use case diagrams (SSD) Examples of robustness diagrams Purpose of this milestone: To take all the information generated in the requirements documents and Ø Ø Capture it graphically Decompose the actions into smaller blocks for allocation to classes. October 6, 2016 SE 430: Lecture 5 58 of 91
Transition to Detailed Design: Roadmap What it consists of: Ø Ø Use Case Diagrams (SSD) for each of your use cases Robustness Diagrams for each of the use cases How you do it: [See notes] Ø Ø Ø Start by diagramming the use cases. From your use case drawing, do the robustness diagram. After you're comfortable that you've got everything, factor the robustness diagrams as you did the use case diagrams. October 6, 2016 SE 430: Lecture 5 59 of 91
Robustness Analysis § A preliminary design step that links analysis to detailed design. § Keeps traceability. § A minimal usage of UML § Verifies that specified system behavior is reasonable given the set of objects in the use case § Provides a completeness and correctness check (alternate courses) § Enables the ongoing discovery of objects (almost certainly missed some objects during conceptual modeling). § Helps ensure that most of the major domain classes are identified before starting object (message) sequence diagrams. October 6, 2016 SE 430: Lecture 5 60 of 91
Robustness Analysis Create a robustness analysis diagram § For a use case: parse the use case text, one sentence at a time. Ø Ø Ø Draw the actors, boundary, entity and controller objects, Draw the needed connections between objects. Fit the basic course and all alternate courses on one diagram. October 6, 2016 SE 430: Lecture 5 61 of 91
Boundary Objects Boundary objects Ø Ø Ø Are objects that actors use to interact with the system. For GUI interfaces, the objects frequently include windows, screens, dialogs and menus, entry buttons. If you have a GUI prototype in place, you can start to identify many of the primary boundary objects that will become part of the system. § Name the boundary objects. § Rewrite the use case text to incorporate the boundary objects by name. October 6, 2016 SE 430: Lecture 5 62 of 91
Boundary Objects (Presentation) Ø Windows, screens and other interface things used by the actors to communicate with the system. <<Boundary>> Boundary Object October 6, 2016 SE 430: Lecture 5 63 of 91
Boundary Objects Boundary objects should be given explicit names. Order. Entry. Window Item. List. Box October 6, 2016 Submit. Button Error. Correction. Window SE 430: Lecture 5 64 of 91
Boundary Objects Boundary objects Ø Ø Ø Can only exchange data with actors and controllers Exist as long as the dialog or screen exists. May also perform limited local validation logic that does not require domain object interactions October 6, 2016 SE 430: Lecture 5 65 of 91
Entity Objects Ø Are usually objects from the domain model that store and fetch data, and perform fundamental computations. <<Entity>> Entity Object October 6, 2016 SE 430: Lecture 5 66 of 91
Entity Objects Entity names come from the problem domain Purchase. Order Item. List POST Transaction October 6, 2016 SE 430: Lecture 5 67 of 91
Entity Objects Ø Ø Ø Only exchange data with controller objects Frequently includes things like forms, orders, checks, etc. May be found in multiple use cases Most contain data that must persist beyond the execution of a single use case (often map to database tables and files). Some are “transient” and exist only for the duration of a use case. October 6, 2016 SE 430: Lecture 5 68 of 91
Control Objects (Application logic) [aka Controllers] Ø Are created to control or direct communication among objects within a use case <<Control>> Control October 6, 2016 SE 430: Lecture 5 69 of 91
Control Objects Control objects often are not real objects but serve as place holders to capture the functionality that "binds" boundary objects to entity objects. Create. Purchase. Order Highlight. Errors October 6, 2016 Get. Item. Values Check. For. Duplicates SE 430: Lecture 5 70 of 91
Control Objects Ø Ø Ø Can talk to boundary, controller or entity objects Contain the application logic, business rules and policies applicable to a given transaction or use case Contain the changeable aspects of a system. Later maintenance is then applied to control objects without disrupting the user interface or the database schema. Most are later discarded when their operations are more appropriately placed in other entity or boundary objects. Some may remain as infrastructure objects in the final design Scope of responsiblity is usually the management of a use case October 6, 2016 SE 430: Lecture 5 71 of 91
Interactions Summary of interactions allowed among entities Ø Ø Ø Boundary objects can only talk with actors and controllers Entity objects only talk with controller objects Controller objects can talk with boundary, entity or controller objects October 6, 2016 SE 430: Lecture 5 72 of 91
Example Application of Robustness Diagram for § Perform Order Entry Use Case The system displays an Order Entry window. The Assistant Trader (AT) first selects the investment involved in the order from a list of available investments. The AT then enters the ticket number that appears on the paper ticket for the order and also specifies whether the trade is a buy or a sell. The system verifies that the ticket number is not a duplicate, if the number is unique, the system creates a new order. When the AT chooses to proceed, the system brings up the appropriate trade entry window, which the AT uses to enter the primary data for the trade. Alternate courses: Ø If the ticket number already exists in the Trade List, the system prompts the AT to enter a new ticket number. Ø If the investment associated with the order does not appear in the Investment List, the system invokes the Define Investment use case. October 6, 2016 SE 430: Lecture 5 73 of 91
Robustness Diagram for Perform Order Entry Use Case Start Here Next October 6, 2016 SE 430: Lecture 5 74 of 91
Robustness Analysis § Each reviewer should be able to do the following for each use case. Ø Ø Read the course of action Finger trace along the associations on the corresponding robustness diagram. See a clear match between text and picture. Identify all the logical functions that must occur in the form of control objects. If it is not possible to fulfill the requirements of the use case, determine what objects are missing and start over. October 6, 2016 SE 430: Lecture 5 75 of 91
Robustness Analysis § Suggestion: Ø Ø Limit the number of controllers per use case between 2 -5. Based on this analysis it may be necessary to keep rewriting the use case until the trace makes sense. § Robustness Analysis Do's and Don'ts Ø Ø Don't violate the robustness diagram rules. Don't start allocating behavior to objects before you have enough information to make good design decisions. The boundary object-controller-entity object pattern correlates with the subject-verb-object pattern of basic English. Controllers serve as placeholders for functionality and system behavior. October 6, 2016 SE 430: Lecture 5 76 of 91
Robustness Analysis Do's and Don'ts Ø Ø Ø Don't allocate behavior to classes on robustness diagrams because you're not likely to have enough information. Don't take too much time trying to perfect robustness diagrams. The robustness diagram serves as a "booster-stage engine" that starts the object-oriented design of use cases. Robustness analysis helps discover objects, allocate attributes, and check the use case text for completeness and correctness. Don't maintain robustness diagrams. Once we've accomplished the overall mission, we don't need to maintain the work product. It's a means to an end, not an end in itself Don't try to do detailed design on robustness diagrams. October 6, 2016 SE 430: Lecture 5 77 of 91
Robustness Analysis Do's and Don'ts § Robustness analysis should be a quick pass across all of the scenarios that will be built. Ø Ø Perform a visual trace between the use case text and the robustness diagram. Update the static model – behavior can't be allocated to classes that don't appear in the model. § When domain modeling and robustness analysis is complete, § Most of the objects in the problem space Ø Ø Ø Will be known and assigned some attributes. Static relationships will have been assigned among the objects on the high-level class diagram, and A few dynamic relationships on your robustness diagrams. October 6, 2016 SE 430: Lecture 5 78 of 91
Drawing Symbols Boundary Object Entity Object Controller See also Arlow & Neustadt, Chapter 8. 4. 3 October 6, 2016 SE 430: Lecture 5 79 of 91
Robustness Analysis § Invented by Doug Rosenberg, author of the ICONIX OOAD process. § The ICONIX process utilizes robustness analysis as a key activity to bridge the gap between the analysis model and the design model. § Doug actually has a few books that demonstrate using robustness analysis (as part of his ICONIX process): Two good examples are » Use Case Driven Object Modeling with UML » Agile Development with ICONIX process October 6, 2016 SE 430: Lecture 5 80 of 91
Function-Class Decomposition (FCD) October 6, 2016 SE 430: Lecture 5 81 of 91
Function-Class Decomposition (FCD) § Function-Class Decomposition is a simple method for functionally grouping domain (conceptual) classes and preliminary design (software) classes. § This functional grouping and allocation of the classes to components helps identify an architecture for a system for which no clear architectural pattern emerges. § FCD is best applied after you have completed your domain class diagram and have worked through your highest-priority design scenarios to find additional abstractions. § Good tutorial at: http: //icse. cs. iastate. edu/sabre/fcd. html October 6, 2016 SE 430: Lecture 5 82 of 91
Function-Class Decomposition (FCD) ‘Lite’ 1. Create system-level (level 1) functional module. 2. Identify an initial set of high-level classes using high-level design scenarios and requirements. 3. Based on class responsibilities and collaborations, create subgroups of classes to maximize cohesion and minimize coupling. 4. Validate grouping by revisiting scenarios and rearranging classes. 5. Treat each resulting group of classes as a level 2 functional module. 6. Analyze next-level design scenarios and requirements. Add additional classes if needed. 7. Repeat steps 3 -6 until no more decomposition is needed. 8. Create UML class diagrams for each leaf functional module. Note: Tutorial mentions use-case maps, a formal way of addressing step 3. October 6, 2016 SE 430: Lecture 5 83 of 91
Iteration 1: Level 1 FCD for VIS VTG Visitor VTG Program Member Services Follow-on Suggestion Member ATS Artifact Configurator Artifact Description Non-member Admissions Administrator Audit Trail Cohesive & loosely-coupled subgroups ATS Visitor VTG Member VTG Program Member Services Follow-on Suggestion Artifact Description Artifact Admissions Audit Trail Non-member Configurator Administrator October 6, 2016 SE 430: Lecture 5 84 of 91
Iteration 2: Level 2 FCD for VIS VTG Visitor VTG Program Member Services Follow-on Suggestion Member ATS Artifact Configurator Artifact Description Non-member Admissions Administrator Audit Trail Virtual Guide Program Visitor Presentation Framework (new) Follow-on Suggestion October 6, 2016 Visitor Audit Tracking (VAT) Audit Trail VIS Support ATS Artifact Description Artifact Admissions Member Services SE 430: Lecture 5 85 of 91
Function-Class Decomposition § Repeat on each new functional module § Check for cohesion and coupling Ø Ø Cohesion: does a module have a single function and do the responsibilities involve all pieces Coupling: how much does a piece in one module need access to pieces in other modules § These can now be thought of as packages October 6, 2016 SE 430: Lecture 5 86 of 91
Summary: Design transition workflow 1. 2. 3. 4. 5. Select candidate architectural patterns for system. Identify architecturally-significant use cases. Identify architectural baseline. Identify subsequent architectural releases. Use CRC cards and design scenarios to identify additional domain and preliminary software classes. 6. Use robustness diagrams to develop a 3 -tier architecture and partition objects into boundary, controller and entity object. [This assumes a 3 -tier architecture makes sense. ] 7. Use function-class decomposition to allocate the classes to appropriate architectural components. Throughout: Identify constraints and enablers. October 6, 2016 SE 430: Lecture 5 87 of 91
Summary § Transition to Detailed Design Ø Ø Software Architecture is needed to decide how to implement the system. This will constrain the design. Architectural Planning allows us to determine the contents of the release and provide a baseline for the system. § Tools and Techniques Ø Ø Design Scenarios – a step by step expansion of the use case into classes and responsibilities The Human Computer Interface: Tiered Architecture – traditional decomposition of a system into functionality Robustness Analysis – how to partition functionality and assign responsibilities. Function-Class Decomposition – the partitioning of system concepts and features into packages and components October 6, 2016 SE 430: Lecture 5 88 of 91
Next Class Topics: Ø Ø The Nature of an Object » Operation contracts; Contracts: Assigning Responsibilities, System Contracts and Dependencies; System Behavior Modeling: » Object behavior: Object relationships; Object interaction diagrams: Communication (Collaboration) Diagrams and Message Sequence Diagrams; Object visibility; » Object state charts: State Diagrams, State Space and Behavior; Reading: Ø Arlow & Neustadt, Ch's 12 -13, 21 October 6, 2016 SE 430: Lecture 5 89 of 91
Midterm Examination “Nobody expects the Spanish Inquisition!” – Monty Python October 6, 2016 SE 430: Lecture 5 90 of 91
Mid-term Examination § Midterm Examination will be on the Desire 2 Learn system starting Saturday, October 8, through Wednesday, October 12. § See important information about Taking Quizzes On-line § On Desire 2 Learn Ø Login to the Desire 2 Learn System (https: //courses. depaul. edu/) Ø Take the Mid-term examination. Ø It will be made available Saturday, October 8, 2016. Ø You must take the exam by COB Wednesday, October 12, 2016. Ø Allow 3 hours (should take about one hour if you are prepared); note: books or notes should not be used. § Midterm study guide October 6, 2016 SE 430: Lecture 5 91 of 91
- Slides: 91