Software Engineering - Essay Example

SOFTWARE ENGINEERING INTRODUCTION In the present day, object-oriented software engineering methods use powerful modeling techniques to assist with the analysis and design of software systems. Modeling using computer-aided software engineering (CASE) tools to render and automatically check the consistency of the models is the common practice in many development environments. The diagrams developed for the models not only assist in the analysis task but also serve as documentation for the state of the development. For example, in the design phase of a Rumbaugh's object modeling technique, the object diagrams, state transition diagrams (STDs), and data-flow diagrams (DFDs) contain most of the information needed to describe all aspects of the software design. Advanced modeling methods, such as the unified modeling language, extend these documentation capabilities and can be used to describe the entire system without the use of traditional documentary texts. The use of the Object Oriented models for documentation may be acceptable for commercial developments but is often not possible for military or government contracts. Commercial software developments usually have a shorter lifecycle with more frequent revisions than military applications. Time to market is a major concern with commercial developments, and because their maintenance will be performed in-house, commercial developers can safely sacrifice documentation for speed. A military system, however, is rarely developed in-house and is often maintained or upgraded by a contractor rather than a developer. In addition, many military developments involve safety-critical systems where careful testing to clearly defined requirements is required for a successful system's implementation. Therefore, sufficient documentation must be available to describe the system requirements for the software tester and maintainer. A written description of the system software requirements that complements the OO models is needed to help testers and maintainers understand the system. Such a written description is often described to as the Software Requirements Specifications (SRS). The SRS is a key document in the software development process. It captures the essential requirements of the system and provides the basis that is used to test the system. If all SRS requirements are mapped to test cases and all test cases are passed, it is reasonable to assume that the system will meet the intended purpose. Although this goal can be achieved through the use of OO models, conversion of models into plain language can reduce ambiguity and help clearly define the system requirements. Description of the Object-Oriented Method Here, we assume a development approach that uses the OO methodology and notation described by James Rumbaugh and augmented by Ivar Jacobson's use case analysis. The discussion here is limited to the requirements analysis phase of the software development lifecycle. The inputs to this phase include the preliminary system architecture in raw terms, i.e., number of processors, preliminary network layout, etc., and a top-level problem statement. In most military developments, the problem statement is in the form of a system or subsystem specification, but for the problem at hand, we describe the common example of a bank's automated teller machine (ATM). There are many outputs of the requirements analysis activity: metrics, trade studies, prototypes, and so forth, but the primary concern here shall be with use cases, models, and SRSs. During requirements analysis, the general course of model design is that the problem statement is studied to identify objects or classes of objects and the relationship between objects. A set of scenarios or use cases are developed that help identify objects and describe the behavior of the system. The objects and their relationships are expressed graphically on an object diagram. A State Transition Diagram depicts the permitted states of an object and the events that cause a change of state. This captures the dynamic behavior of the system. Finally, functional relationships and data requirements are shown on a DFD. A common problem in requirements analysis is determining the difference between a software requirement and a design implementation. Since the Object Oriented models created during the requirements analysis phase are adorned with design information in later phases, there is a tendency to over specify, which adds design constraints to requirements. The Institute of Electrical and Electronics Engineers (IEEE) recommended practice for SRSs provides guidance for differentiating requirements from design: A requirement specifies an externally visible function or attribute of a system. A design describes a particular subcomponent of a system or its interfaces with other subcomponents or both. These criteria should be applied throughout the creation of the requirements analysis diagrams; the addition of any design details to the requirements models should be delayed until the design phase. Project Organization In most developments, an SRS is produced for each computer software configuration item (CSCI). Therefore, partitioning the system into CSCIs must take place prior to or during requirements analysis. In general, the allocation of requirements to a particular CSCI has no externally visible consequence and, under the IEEE guidelines discussed above, should not be considered in requirements analysis. Recognizing that partitioning functionality into CSCIs is a design decision imposed on requirements, there are some partitioning considerations that will enhance documentation and maintainability as well as provide manageable CSCIs for development: CSCIs should be partitioned to minimize communication with other CSCIs. A CSCI should not be assigned to multiple processors unless all are under the control of a single operating system. A CSCI spread across several processors that require complex communication protocols or different communication pathways for interprocess communication can add confusion and mask constraints. The CSCI should be of a reasonable size; it should not contain an excessive number of disparate objects. These are guidelines that should be applied where technically and economically feasible. However, when dealing with a large distributed system, mapping a single CSCI to a single processor greatly simplifies documentation, performance analysis, and identification of interfaces thus making the system easier to understand. The format and content of the SRS is specified by the Data item description (DID) for the SRS. The DID invites developers to modify the DID guidelines to tailor the SRS to the development. Specific attention is directed to the use of CASE tools. If the CASE tool permits the automatic capture of the material required by the DID in a format different from the DID, it is recommended that the DID be tailored to conform to the output of the CASE tool. From experience, modification of the CASE tool output to meet the DID format is difficult and rarely cost-effective. The output of the modified CASE tool often requires extensive manual modification to achieve acceptable results. Experience shows that it is better to accept the CASE tool output and modify the DID than to try to modify the CASE tool output to be 100 percent DID compliant. Design of the Use Case We use three techniques in the modeling-- Use-Case analysis (Jacobson, et. al.), CRC cards (Beck/Cunningham), and "Design by Walking Around" (explained below). Use Case modeling examines the system from the viewpoint of a single user interacting with the proposed system in a single way. The prototypical use case is performing a cash withdrawal from an ATM. The next figure illustrates six different use cases performed by three different external actors on the ATM system. The first step in the requirements analysis phase is to develop use cases from the top-level problem statement. If our task is to build an ATM, some typical use cases could be: - Make a deposit. - Make a withdrawal. - Check account balance. - Pay a loan. Fig: An ATM System Use Case A use case details the sequence of interactions that occurs. The analysis of a system consists of a set of use cases. The following is the beginning of the development of one of the use cases of the above figure. The use cases are later used to verify the resulting system. Each use case is designed as a collection of interacting objects to carry out that case. The same object may participate in many use cases. The total responsibilities of an object are the union of its responsibilities in all of the use cases in which it participates. CRC cards are a way to detail the Classes, Responsibilities, and Collaborations of the objects in a system. Objects are instantiated from classes. They have responsibilities. and they collaborate with other objects to fulfill a use case. Class Diagram for the ATM System The Figure in the Next Page shows a simple class diagram of an ATM system. This diagram is interesting both for what it shows, and for what it does not show. Note that all the interfaces have been marked. It is considered crucial to make sure that the readers know what classes are intended to be represented as interfaces and which have been intended to be implemented. For example, the diagram immediately tells us that Withdrawal Transaction talks to a Cash Dispenser interface. Clearly some class in the system will have to implement the Cash Dispenser, but in this diagram we don't care which class it is. Note that the documentation of the methods of the various UI interfaces has not been very particular. Certainly, WithdrawalGUI will need more than just the two methods shown there. We must also note promptForAccount and informCashDispenserEmpty. Putting those methods in the diagram would just clutter it. By providing a representative batch of methods, we have given the reader the idea. That's all that's really necessary. Again note the convention of horizontal association and vertical inheritance. This really helps to differentiate these vastly different kinds of relationships. Without a convention like this it can be hard to tease the meaning out of the tangle. Notice how the diagram has been separated into three distinct zones. The transactions and their actions are on the left, the various UI interfaces are all on the right, and the UI implementation is on the bottom. Note also that the connections between the groupings are minimal and regular. In one case it is three associations, all pointing the same way. In the other case it is three inheritance relationships all merged into a single line. The grouping, and the way they are connected help the reader to see the diagram in coherent pieces. Fig: Class Diagram of an ATM System Details of the Class Diagram There are a vast number of details and adornments that can be added to UML class diagrams. Most of the time these details and adornments should not be added. But there are times when they can be helpful. Also their implementation in the JAVA programming language is also shown alongside. Interfaces All the methods of classes marked with this stereotype are abstract. None of the methods can be implemented. Moreover, interface classes can have no instance variables. The only variables they can have are static variables. This corresponds exactly to Java interfaces Fig: Interface Abstract Classes In UML there are two ways to denote that a class or a method is abstract. You can write the name in italics, or you can use the {abstract} property. Fig: Abstract Classes Aggregation Aggregation is a special form of association that connotes a "whole/part" relationship. Figure below shows how it is drawn and implemented. Notice that the implementation shown in Figure 3-14 is indistinguishable from association. Unfortunately, UML does not provide a strong definition for this type of relationship. This leads to confusion because various programmers and analysts adopt their own pet definitions for the relationship. The one hard rule that UML gives us regarding aggregations is simply this: A whole cannot be its own part. Therefore instances cannot form cycles of aggregations. A single object cannot be an aggregate of itself, two objects cannot be aggregates of each other, three objects cannot form a ring of aggregation, and so on. See Figure below. Association stereotypes Associations can be labeled with stereotypes that change their meaning. The figure in the next page shows the ones that are used most often. Fig: Association Stereotypes The create stereotype indicates that the target of the association is created by the source. The implication is that the source creates the target and then passes it around to other parts of the system. In the example we have shown a typical factory. The local stereotype is used when the source class creates an instance of the target and holds it in a local variable. The implication is that the created instance does not survive the member function that creates it. Thus, it is not held by any instance variable nor passed around the system in any way. The parameter stereotype shows that the source class gains access to the target instance though the parameter of one of its member functions. Again, the implication is that the source forgets all about this object once the member function returns. The target is not saved in an instance variable. Using dashed dependency arrows, as the diagram shows, is a common and convenient idiom for denoting parameters. Usually it is preferred to use the parameter stereotype. The delegate stereotype is used when the source class forwards a member function invocation to the target. There are a number of design patterns where this technique is applied, such as PROXY, DECORATOR, and COMPOSITE. Since these patterns are used a lot, we find the notation helpful. State model for a transaction use case The figure below is an example of a State-Chart diagram in an ATM system. Objects have both behavior and state or, in other words, they do things and they know things. Some objects do and know more things, or at least more complicated things, than other objects. Some objects are incredibly complicated, so complex that developers can have difficulty understanding them. To understand complex classes better, particularly those that act in different manners depending on their state, we should develop one or more UML state machine diagrams, formerly called state chart diagrams in UML 1.x, describing how their instances work. UML state machine diagrams depict the various states that an object may be in and the transitions between those states. In fact, in other modeling languages, it is common for this type of a diagram to be called a state-transition diagram or even simply a state diagram. A state represents a stage in the behavior pattern of an object, and like UML activity diagrams it is possible to have initial states and final states. An initial state, also called a creation state, is the one that an object is in when it is first created, whereas a final state is one in which no transitions lead out of. A transition is a progression from one state to another and will be triggered by an event that is either internal or external to the object. States are represented by the values of the attributes of an object. In the diagram above, the various states are Getting Specifics, Sending to Bank, Completing the transaction, Handling invalid PIN, Printing Receipt, and Asking if the Customer wants another. We indicate the methods to run during the state when we want to indicate a method is to be run continuously, perhaps a method that polls other objects for information or a method that implements the logic of an important business process. Methods to be invoked when the object moves from state to state are indicated by the keyword approved, as you see between the Handling invalid PIN and Completing Transaction states in Figure. The capability to indicate method invocations between states is useful because it enables us to avoid documenting the same method several times on each of the transitions that enter or exit the state, respectively. Transitions are the result of the invocation of a method that causes an important change in state. Understanding that not all method invocations will result in transitions is important. For example, the invocation of a getter method likely wouldn't cause a transition because it isn't changing the state of the object (unless lazy initialization is being applied). Furthermore, Figure indicates an attempt to approve a customer may not result in the object changing state, unless it is determined that the customer's identity has been authenticated, even though the state of the object changes (another customer is accessing at the same time). We can see that transitions are a reflection of our business rules. For example, We see that we can attempt to withdraw cash without bothering about the balance in the account, but the ATM validates tat there is enough money in the account and only then allows the customer to withdraw the required amount. We can have recursive transitions, also called self-transitions, which start and end in the same state. An example of this could be the ATM verifying a PIN more than once. Collaboration Diagram for ATM System A Sequence diagram is dynamic, and, more importantly, is time ordered. A Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves; in other words, it shows the dynamic interaction of the objects in a system. A distinguishing feature of a Collaboration diagram is that it shows the objects and their association with other objects in the system apart from how they interact with each other. The association between objects is not represented in a Sequence diagram. Modeling objects in a system and representing the associations between the objects as links easily represent a Collaboration diagram. Arrows denote the interaction between the objects. To identify the sequence of invocation of these objects, a number is placed next to each of these arrows. A Collaboration diagram consists of the following elements: 1) Object: The objects interacting with each other in the system. Depicted by a rectangle with the name of the object in it, preceded by a colon and underlined. 2) Relation/Association: A link connecting the associated objects. Qualifiers can be placed on either end of the association to depict cardinality. 3) Messages: An arrow pointing from the commencing object to the destination object shows the interaction between the objects. The number represents the order/sequence of this interaction. UML Collaboration diagrams (interaction diagrams) illustrate the relationship and interaction between software objects. They require use cases, system operation contracts, and domain model to already exist. The collaboration diagram illustrates messages being sent between classes and objects (instances). A diagram is created for each system operation that relates to the current development cycle (iteration). When creating collaboration diagrams, patterns are used to justify relationships. Patterns are best principles for assigning responsibilities to objects and are described further in the section on patterns. There are two main types of patterns used for assigning responsibilities, which are evaluative patterns, and driving patterns. Each system operation initiates a collaboration diagram. Therefore, there is a collaboration diagram for every system operation. The figure below depicts a Collaboration diagram for an ATM diagram: Final evaluation and Conclusion The above report has depicted the various diagrams that have been drawn to give an insight to the reader regarding the development of a concrete ATM Network. Therefore, all the necessary construction and architecture of an ATM system has been shown. It is nowadays deemed profitable for the establishment of an ATM chain. The implementation of such a design will help in the establishment of what are today popularly called as ATM outlets, which will increase the business operations of the bank along with ensuring that more customers are attracted to such a practice owing to the fastness and security in using an ATM for Banking transactions. The cost involved in any kind of banking transactions is slated to reduce with the establishment of such an ATM network, which has proved that it can do wonders to a company's revenues by attracting more customers to maintain ATM accounts. An added advantage to all this is that such transaction usually require minimal time owing to the high-speed infrastructure that is often used for establishing an ATM network. With all the above arguments and by supplying all the previously discussed diagrams, it can be concluded that the proposed set-up of an ATM network is a very effective way of cutting down on the overall costs, minimizing transaction times, and lesser waiting times which eventually attracts more customers. The waiting times are reduced because the ATM centers are scattered around a geographical area and are hence accessible at all important points. As such, they are virtually empty most of the times due to which the amount of time that a customer has to spend for transactions gets greatly reduced. Finally, I would like to end with a quote by the Rothschild Brothers: "The few who understand the system, will either be so interested from it's profits or so dependant on it's favors, that there will be no opposition from that class." REFERENCES - Grady, Booch and Rambaugh (1997), UML-user guide. New York: O'Reilly Read More