Recall The Team SkillsBuilding the Right SystemChapter 25 From Use Cases to ImplementationMapping Requirements Directly to Design and CodeThe Orthogonality ProblemSlide 6Reasons of orthogonality problemAvoiding Orthogonality problemArchitecture of Software SystemsThe “4+1” views of ArchitectureThe “4+1” views of ArchtiectureHOLIS Case StudyRealizing Use Cases in the Design ModelA Use-Case Realization in the Design ModelStructural and Behavioural Aspects of CollaborationsSlide 16Class Diagram for the HOLIS Emergency Message Sequence CollaborationBehavioral Aspects of the HOLIS Emergency Message Sequence CollaborationUsing Collaborations to Realize Sets of Individual RequirementsFrom Design to ImplementationKey PointsRecall The Team Skills1. Analyzing the Problem (with 5 steps)2. Understanding User and Stakeholder Needs3. Defining the System4. Managing Scope5. Refining the System Definition6. Building the Right SystemBuilding the Right SystemCh 25. From Use Cases to ImplementationCh 26. From Use Cases to Test CasesCh 27. Tracing RequirementsCh 28. Managing ChangeCh 29. Assessing Requirements Quality in Iterative DevelopmentChapter 25From Use Cases to Implementation The Orthogonality Problem Use Cases realization in the Design Model Collaboration From Design to ImplementationMapping Requirements Directly to Design and CodeThe Orthogonality ProblemIt's probably fairly straightforward to find, inspect, and validate the code that fulfills requirements such as"Support up to an eight-digit floating-point input parameter" However, things get a little trickier for requirements such as "The system shall handle up to 100,000 trades an hour"The Orthogonality ProblemThere is little correlation between the requirement and the design and implementation; they are orthogonal, or nearly so. In other words, the form of our requirements and the form of our design and implementation are different.There is no one-to-one mapping to make implementation and validation easier.Reasons of orthogonality problemRequirements speak of real-world item, while code speaks about stacks, queues, and algorithms.Some requirements (like non-functional req.s) have little to do with logical structure of code.Some functional req.s require other parts of the system to interact with.Good system design is more related to resources management, reusing code, and applying purchased components.Avoiding Orthogonality problemBy using object-orientation ..why?ReuseNo changes in real world items implies no changes in codeAbstraction and moving from classes to objectsClasses collaborationArchitecture of Software SystemsSoftware Architecture involvesDescription of elements from which the systems are built, interactions amongst those elements, patterns that guide their composition, and constraints on those patterns. (Shaw and Garlan, 1996)Why architecture?understand what the system doesUnderstand how it worksThink and work on pieces of the systemExtend the systemReuse parts of the system to build another oneThe “4+1” views of ArchitectureDifferent groups of stakeholders need to see the architecture from different viewsKruchten (1995) “4+1” views:Logical view: the functionality of the systemImplementation view: source codes, libraries, object classes, .. etcProcess view: operations of the system and interfaces with othersDeployment view: operating systems and platformsUse case view: ties all views togetherThe “4+1” views of ArchtiectureLogical viewProcess viewImplementation viewDeployment viewUse case viewProgrammerSoftware ManagementSystem EngineeringSystem topologyDelivery, installationcommunicationEnd UserFunctionalityDesigner/TesterBehaviorSystem IntegratorsPerformanceScalabilityThroughputHOLIS Case Study1. Logical view: describes the various classes and subsystems that implemented behavior2. Implementation view: describes the various code artifacts for HOLIS3. Process view: demonstrate how multitasking is done4. Deployment view: how HOLIS is distributed across CCU, Control switch, homeowner’s PCs.Realizing Use Cases in the Design ModelUse cases are realized via collaborations, which are societies of classes, interfaces, subsystems, or other elements that cooperate to achieve some behavior. A common UML stereotype, the use-case realization, is used for this purpose: A special form of collaboration, one that shows how the functionality of a specific use case is achieved in the design model. Symbolic representation of a collaborationExampleA Use-Case Realization in the Design ModelStructural and Behavioural Aspects of CollaborationsCollaborations have two aspects: A structural part that specifies the static structure of the system (the classes, elements, interfaces, and subsystems on which the implementation is structured). A behavioral part that specifies the dynamics of how the elements interact to accomplish the result.Structural and Behavioural Aspects of CollaborationsA class diagram represents the structural aspects, whereas an interaction diagram (sequence or collaboration) represents the behavioural aspects.Class Diagram for the HOLIS Emergency Message Sequence CollaborationBehavioral Aspects of the HOLIS Emergency Message Sequence CollaborationUsing Collaborations to Realize Sets of Individual RequirementsFrom Design to Implementation By modeling the system this way, we can ensure that the significant use cases and requirements of the system are properly realized in the design model. In turn, this helps ensure that the software design conforms to the requirements. The next step follows quite logically, although admittedly not easily. The classes and the objects defined in the design model are further refined in the iterative design process and eventually implemented in terms of the physical software components—source files, binaries, executables, and others—that will be used to create the executable software.Key PointsSome requirements map well from design to implementation in code.Other requirements have little correlation to design and implementation; the form of the requirement differs from the form of the design and implementation (the problem of orthogonality).Object orientation and use cases can help alleviate the problem of orthogonality.Use cases drive design by allowing all stakeholders to examine the proposed system
View Full Document