Chapter 14 n ComponentLevel Design Slide Set to

Chapter 14 n Component-Level Design Slide Set to accompany Software Engineering: A Practitioner’s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 1

What is a Component? n OMG Unified Modeling Language Specification [OMG 01] defines a component as n n n “… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. ”” OO view: a component contains a set of collaborating classes Conventional view: a component contains processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 2

OO Component These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 3

Source: Martin, R. , “Design Principles and Design Patterns” Symptoms of Rotting Design (1/4) n Rigidity: the tendency for SW to be difficult to change n n n Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multiweek marathon of change in module after module Managers fear to allow engineers to fix non-critical problems. This reluctance derives from the fact that they don’t know, with any reliability, when the engineers will be finished. When the manager’s fears become so acute that they refuse to allow changes to software, official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 4

Source: Martin, R. , “Design Principles and Design Patterns” Symptoms of Rotting Design (2/4) n Fragility: the tendency of the SW to break in many places every time it is changed. n n Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. As the fragility becomes worse, every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. . These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 5

Source: Martin, R. , “Design Principles and Design Patterns” Symptoms of Rotting Design (3/4) n Immobility: the inability to reuse SW from other projects or from parts of the same project. n An engineer will discover that he needs a module that is similar to one that another engineer wrote. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 6

Source: Martin, R. , “Design Principles and Design Patterns” Symptoms of Rotting Design (4/4) n Viscosity (of the design, and of the environment). n n When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i. e. they are hacks. ) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. Viscosity of environment comes about when the development environment is slow and inefficient. For example, • if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optimal from a design point of view. • If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 7

Basic Design Principles n n n n The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification. The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base classes. Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions. ” The Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one general purpose interface. The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of release. ” The Common Closure Principle (CCP). “Classes that change together belong together. ” The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be grouped together. ” Source: Martin, R. , “Design Principles and Design Patterns, ” downloaded from http: www. objectmentor. com, 2000. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 8

Design Guidelines n n n Components n Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model Interfaces n Interfaces provide important information about communication and collaboration (as well as helping us to achieve the OCP (open-closed principle)) Dependencies and Inheritance n It is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes). These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 9

Cohesion n OO view: n n cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself Levels of cohesion n n n Functional Layer Communicational: all operations that access the same data Sequential: passing data from the first op to the following ops Procedural: similar to Sequential, not without data passing Temporal: ex. Error handling class, initialization class Utility: ex. Statistics class 10

Cohesion in Action (pg 297) n The scene: n n n Jamie's cubicle. The players: n n n Jamie, Ed members of the Safe. Home software engineering team who are working on the surveillance function. The conversation: Ed: I have a first-cut design of the camera component. Jamie: Wanna do a quick review? Ed: I guess. . . but really, I'd like your input on something (Jamie gestures for him to continue. ) Ed: We originally defined five operations for camera. Look. . . [shows Jamie the list] n n n determine. Type() tells me the type of camera. translate. Location() allows me to move the camera around the floor plan. display. ID() gets the camera ID and displays it near the camera icon. display. View() shows me the field of view of the camera graphically. display. Zoom() shows me the magnification of the camera graphically. Ed: I've designed each separately, and they're pretty simple operations. So I thought 11 11

n n n it might be a good idea to combine all of the display operations into just one that's called display. Camera()--it'll show the ID, the view, and the zoom. Whaddaya think? Jamie: Not sure that's such a good idea. Ed (frowning): Why? All of these little ops can cause headaches. Jamie: The problem with combining them is we lose cohesion. You know, the display. Camera() op won't be single-minded. n n n Ed (mildly exasperated): So what? The whole thing will be less than 100 source lines, max. It'll be easier to implement, I think. Jamie: And what if marketing decides to change the way that we represent the view field? Ed: I'll just jump into the display. Camera() op and make the mod. Jamie: What about side effects? Ed: Whaddaya mean? Jamie: Well, say you make the change but inadvertently create a problem with the ID display. 12 12

n n n Ed: I wouldn't be that sloppy. Jamie: Maybe not, but what if some support person two years from now has to make the mod. He might not understand the op as well as you do and, who knows, he might be sloppy. Ed: So you're against it? Jamie: You're the designer. . . it's your decision. . . just be sure you understand the consequences of low cohesion. Ed (thinking a moment): Maybe we'll go with separate display ops. n Jamie: Good decision. 13 13

Coupling n Conventional view: n n OO view: n n The degree to which a component is connected to other components and to the external world a qualitative measure of the degree to which classes are connected to one another Level of coupling n n n n Content: one component modifies data of another component Common: when components make use of a global variable Control: A() invokes B() and passes a control flag to B Routine call: one op invokes another Type use: class A uses a data type defined in class B Inclusion or import External coupling: when a component collaborates with infrastructure components 14

Source: Martin, R. , “Design Principles and Design Patterns” 15

The OCP in Action (pg 293) n The scene: n n The players: n n n Vinod's cubicle. Vinod, Shakira members of the Safe. Home software engineering team. The conversation: Vinod: I just got a call from Doug [the team manager]. He says marketing wants to add a new sensor. Shakira (smirking): Not again, jeez! Vinod: Yeah. . . and you're not going to believe what these n n n guys have come up with. Shakira: Amaze me. Vinod (laughing): They call it a doggie angst sensor. Shakira: Say what? Vinod: It's for people who leave their pets home in apartments or condos or houses that are close to one another. The dog starts to bark. The neighbor gets angry and complains. With this sensor, if the dog barks for more than, say, a minute, the sensor sets a special alarm mode that calls the owner on his or her cell phone. Shakira: You're kidding me, right? 16 16

n n n Vinod: Nope. Doug wants to know how much time it's going to take to add it to the security function. Shakira (thinking a moment): Not much. . . look. [She shows Vinod Figure 11. 4] We've isolated the actual sensor classes behind the sensor interface. As long as we have specs for the doggie sensor, adding it should be a piece of cake. Only thing I'll have to do is create an appropriate component. . . uh, class, for it. No change to the Detector component at all. Vinod: So I'll tell Doug it's no big deal Window/ door sensor n n n Shakira: Knowing Doug, he'll keep us focused and not deliver the doggie thing until the next release. Vinod: That's not a bad thing, but can you implement now if he wants you to? Shakira: Yeah, the way we designed the interface lets me do it with no hassle. Vinod: have you ever heard of the open-closed principle? Shakira: Never heard of it Vinod (smiling): Not a problem <<interface>> Sensor read() enable() disable() test() Smoke sensor Detector Motion detector Heat sensor CO 2 sensor 17

Component Level Design-I n n Step 1. Identify all design classes that correspond to the problem domain. Step 2. Identify all design classes that correspond to the infrastructure domain. n n Ex. GUI components, OS components, object & data management components, etc Step 3. Elaborate all design classes that are not acquired as reusable components. n n Step 3 a. Specify message details when classes or component collaborate. Step 3 b. Identify appropriate interfaces for each component. Step 3 c. Elaborate attributes and define data types and data structures required to implement them. Step 3 d. Describe processing flow (activity diagram) within each operation in detail. 18

Component-Level Design-II n n Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them. Step 5. Develop and elaborate behavioral representations (statechart) for a class or component. Step 6. Elaborate deployment diagrams to provide additional implementation detail. Step 7. Factor every component-level design representation and always consider alternatives. 19

Collaboration Diagram These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 20

Refactoring (see page 3) 21

Activity Diagram 22

Statechart 23

Designing Conventional Components n n n The design of processing logic is governed by the basic principles of algorithm design and structured programming The design of data structures is defined by the data model developed for the system The design of interfaces is governed by the collaborations that a component must effect These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 24

Component-Based Development n When faced with the possibility of reuse, the software team asks: n n Are commercial off-the-shelf (COTS) components available to implement the requirement? Are internally-developed reusable components available to implement the requirement? Are the interfaces for available components compatible within the architecture of the system to be built? At the same time, they are faced with the following impediments to reuse. . . These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 25

Impediments to Reuse n n n Few companies and organizations have anything that even slightly resembles a comprehensive software reusability plan. Although an increasing number of software vendors currently sell tools or components that provide direct assistance for software reuse, the majority of software developers do not use them. Relatively little training is available to help software engineers and managers understand apply reuse. Many software practitioners continue to believe that reuse is “more trouble than it’s worth. ” Many companies continue to encourage of software development methodologies which do not facilitate reuse Few companies provide an incentives to produce reusable program components. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 26

The CBSE Process These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 27

Domain Engineering 1. Define the domain to be investigated. 2. Categorize the items extracted from the domain. 3. Collect a representative sample of applications in the domain. 4. Analyze each application in the sample. 5. Develop an analysis model for the objects. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 28

Identifying Reusable Components • Is component functionality required on future implementations? • How common is the component's function within the domain? • Is there duplication of the component's function within the domain? • Is the component hardware-dependent? • Does the hardware remain unchanged between implementations? • Can the hardware specifics be removed to another component? • Is the design optimized enough for the next implementation? • Can we parameterize a non-reusable component so that it becomes reusable? • Is the component reusable in many implementations with only minor changes? • Is reuse through modification feasible? • Can a non-reusable component be decomposed to yield reusable components? • How valid is component decomposition for reuse? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 29

Component-Based SE n n n a library of components must be available components should have a consistent structure a standard should exist, e. g. , n n n OMG/CORBA Microsoft COM Sun Java. Beans These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 30

CBSE Activities n n Component qualification Component adaptation Component composition Component update These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 31

Qualification Before a component can be used, you must consider: • application programming interface (API) • development and integration tools required by the component • run-time requirements including resource usage (e. g. , memory or storage), timing or speed, and network protocol • service requirements including operating system interfaces and support from other components • security features including access controls and authentication protocol • embedded design assumptions including the use of specific numerical or non-numerical algorithms • exception handling These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 32

Adaptation The implication of “easy integration” is: (1) that consistent methods of resource management have been implemented for all components in the library; (2) that common activities such as data management exist for all components, and (3) that interfaces within the architecture and with the external environment have been implemented in a consistent manner. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 33

Composition n n An infrastructure must be established to bind components together Architectural ingredients for composition include: n n Data exchange model Automation Structured storage Underlying object model These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 34

OMG/ CORBA n n n The Object Management Group has published a common object request broker architecture (OMG/CORBA). An object request broker (ORB) provides services that enable reusable components (objects) to communicate with other components, regardless of their location within a system. Integration of CORBA components (without modification) within a system is assured if an interface definition language (IDL) interface is created for every component. Objects within the client application request one or more services from the ORB server. Requests are made via an IDL or dynamically at run time. An interface repository contains all necessary information about the service’s request and response formats. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 35

ORB Architecture These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 36

Microsoft COM n n The component object model (COM) provides a specification for using components produced by various vendors within a single application running under the Windows operating system. COM encompasses two elements: n n COM interfaces (implemented as COM objects) a set of mechanisms for registering and passing messages between COM interfaces. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 37

Sun Java. Beans n n The Java. Beans component system is a portable, platform independent CBSE infrastructure developed using the Java programming language. The Java. Beans component system encompasses a set of tools, called the Bean Development Kit (BDK), that allows developers to n n n analyze how existing Beans (components) work customize their behavior and appearance establish mechanisms for coordination and communication develop custom Beans for use in a specific application test and evaluate Bean behavior. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (Mc. Graw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 38