7. Complex Models (and the Origins of UML). Overview 7.1 Issues 7.2 Object Modeling Technique 7.3 Use Case Approach. 7.1 Issues. Complex systems demand superior methods must cover specification & design thoroughly must provide a rich repertoire of concepts and tools
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Rumbaugh et al.
Attempts to integrate several traditional methods with object-oriented analysis
Combined with the (Grady) Booch method, and Jacobsen’s Use Cases, led to UML
application-specific information (structure) is captured in terms of objects having attributes and operations
classes and inheritance are used to generalize objects
links and associations define logical relationships among objects and classes
the dynamic behavior of objects is captured using state machine models
the processing of environmental inputs is captured by means of a dataflow model7.2 Object Modeling Technique
operations (services) it provides
Objects often are immediately identifiable in the application
E.g., look for nouns in RDD/SRS
Initial definitions may be misleading
may need rethinking (semantics)
may refactor or extend accordingly
What does it do?
What happens in the US?
What happens in Australia?Objects
RDD (requirements model)
domain object model
use case model (scenarios)
SRS (analysis model)
object-oriented model of the functionality7.3 Use Case Approach
Critical reviews involving requirements are
Highly specialized reviews relating to requirements include
error pattern analysisTechnical Objectives
These notions must rely on criteria provided by some underlying model
are all inputs used?
are all outputs produced?
is the information needed to carry out each function available?
are interfaces used in a manner inconsistent with the physical reality?Requirements Verification
Its goal is to ensure that the requirements are an accurate reflection of the customer’s needs
as presented originally by the customer in the RDD
as reformulated by the technical team in the SRS
Customer participation is critical
The customer needs access to information but not the ability to read the documentation
expert technical support
Consistency and traceability between RDD and SRS are important in the validationRequirements Validation
all functional requirements have been allocated to the design—traceability
all constraints are likely to be satisfied by the realization—design evaluation studies
The top-level design (reflecting all critical design decisions) is checked against the SRS
constraints satisfactionDesign Verification