You are on page 1of 8

Laureate Online Education Systems Analysis and Design using an Object-Oriented Approach

All rights reserved, 20042010. The Systems Analysis and Design using an ObjectOriented Approach module, in all its parts: syllabus, guidelines, lectures, discussion questions, technical notes, images, labs, projects and any additional material is a copyright of Laureate Online Education B.V. Seminar 1

Subject: Introduction to Systems Analysis and Design

Welcome to Systems Analysis and Design using an Object-Oriented Approach. The main goal of this module is for you to learn how to use object-oriented (OO) techniques to analyse complex problems and to design software solutions for those problems. We will use a systematic approach to learning these techniques, where we will look at each stage of development in turn. In practice, analysis and design do not progress as simply as might be implied from this learning environment, but the methods and techniques you learn in this module will be directly applicable to a real world environment. This module is one of the few that has an explicit pre-requisite. It is assumed that you are familiar with OO concepts. This knowledge can be from Object-Oriented Programming in C++ or Java modules or from your own experience. In this module, we will build on your existing knowledge to better prepare you to work in a modern software development environment. This module will not require any programming, so it does not matter which programming language you used to learn OO programming. The language that will be used is the Unified Modeling Language (UML), which is the industry standard for documenting OO analysis and design models. While this module is about OO analysis and design and the use of UML in this context, this week we will focus on setting the background against which you will learn how to perform systems analysis and design. Over the next six weeks, we will look at the different stages of systems analysis and design and discuss how to use UML within each stage. In the final week, we wrap up by considering the breadth of analysis and design and pulling it all into a coherent process. History Object-oriented ideas date back to the early 1960s, when they were initially used in some experimental graphical environments. These ideas then migrated into programming languages in the late 1960s with the Simula language. Analysis and design methods using OO concepts first began to appear in the mid-1980s. Each method had its own notation or modelling language, which led to some confusion. UML started as an effort to merge the work of two leading methodologists, Grady Booch and Jim Rumbaugh, at Rational Corporation. At about the same time, the Object Management Group (OMG) put out a call for proposals for a standard object modelling language. The notation that Booch and Rumbaugh had developed was submitted by Rational to the OMG and, over a series of deliberations and revisions, has become the current standard we will be using in this module (OMG, 2007).

Currently, the OMG is finalising a major extension to UML, which will become version 2.0 (UML, 2007). This module will primarily use the core of UML version 2.0. Some of the extensions in UML 2.0 that we will not consider are domain specific or rely on specific techniques. Software Systems The textbook uses the term information system in a very general manner to describe a system that allows for the storage of, manipulation of and access to information (or more accurately, data). This system may be a manual system, such as a simple address book, or it may be an automated system controlled by software, such as an on-line auction system. In this module, we will focus on providing software solutions to problems, so we will use the term software system. Second, the term information system is used in some regions to refer to businessoriented applications; however, the techniques you will learn in this module are more widely applicable across a range of problem domains, and the textbook takes a wider view of software development as well. When considering a system, whether manual or software, you must be aware of the environment in which it will operate. It is the awareness of the environment that allows the developer to understand the purpose of the system and to understand how it will be used. An important aspect of this is determining the scope of the system. The scope indicates 1) which parts of the environment the system will control and manipulate, and 2) which parts of the environment are outside of the system but may impact on the system by using it directly or indirectly. The scope determines the system boundary, which provides the interface between the system and those things that interact with the system. Another important issue is abstraction. Abstraction is the technique used to determine what the system needs to know about the environment. With your knowledge of OO programming, you should already be familiar with the concept of abstraction and how an object is a representation of some entity in the problem domain. This same concept is used directly in analysis and design when identifying and designing objects and classes for a software system. However, abstraction is used at all stages of development and provides a filter for viewing the complexities of an environment and deciding what is important and what can be ignored. For example, a map is an abstract representation of a geographical area. A paper map that contained all of the data about an area would have to be at least as large as that area. This naturally would not be very useful. In reality, maps are very small representations of large areas. Maps provide only limited information about the area; for example, it may only be a street map containing streets and their names. Maps can be drawn on a small scale and provide enough information to allow someone to navigate around a city, but they do not contain all the information about the city and not even all the information about the streets (e.g., the location of street lamps and gutters are not usually included in a map). Thus, abstraction is the technique used to identify what is important about the environment (streets, directions and intersections in our example), and it allows the developer to only concentrate on those details. System Development Stages When analysing complex systems and designing software solutions for these systems, there is a process that is followed. First, we will consider the basic stages that occur in systems development. The textbook readings, and in particular the discussion questions, will then

explore software development processes in more depth. (Note: Often the terms life cycle, process, method, or methodology are used interchangeably to refer to the steps that are followed when developing a software system.) The basic stages of systems development are analysis, design, implementation, testing, release and maintenance. Different processes (or life cycles, as they are referred to in the textbook) may use different terms and may split these stages into smaller steps, but the core ideas of these stages must be realised in systems development. The other important point is that each process will nominate a path of how to navigate through these steps, which can be considerably different in different processes. This module focuses on the analysis and design stages but considers their impact on all the other stages. Analysis is considered by some to be the most important stage because it lays a foundation of understanding upon which the rest of the systems development is constructed. Analysis is concerned with understanding the system and its context in order for an appropriate solution to be designed. We will consider two major aspects of analysis, requirements analysis and domain analysis. Requirements analysis is where you as a developer attempt to understand what the end users want and need the system to accomplish. The key issues are ensuring that all possibilities are explored and that you and the end users understand each other. Domain analysis is where the developer needs to understand the environment in which the system will work and how the system will interact with other systems in that environment. (These other systems may or may not be software systems.) In OO analysis, it is this understanding of the problem domain and the model of the system in this domain that leads naturally to a design for the software system. Design is where the structure of the software system is decided. Software is a complex product, and there are several levels of abstraction used in its design. Architectural design considers the gross structure of the system. High-level design considers the structure of the main components of the system. Detailed design considers the internals of each component and how it works. A system may also be split into sub-systems to provide more abstraction layers in development. Whereas analysis may be considered to provide a foundation of understanding about the system, design provides the framework that makes the system possible. We will consider architectural, high-level and detailed design in this module, but our focus will be more on architectural and high-level design. It is assumed that your prerequisite knowledge of OO concepts provided you with an understanding of detailed design. Implementation is when the design is translated into code in some programming language. Towards the end of this module, we will consider how UML helps with planning this stage in large systems, but it is assumed that you are capable of doing simple implementation based on your previous experience. Testing involves both planning how to perform tests and actually conducting those tests. This should be done concurrently with all the other stages of development. During analysis, the acceptance tests should be constructed to find requirements that the system does not implement (or at least, not correctly). During design, system and integration tests should be constructed to find faults with the structure of the system. During implementation, unit tests should be constructed and executed to find faults with classes as they are being built. Once all unit tests for a sub-system are passed, then those classes should be integrated together and have their integration tests executed. When integration is complete, system tests can be executed. Acceptance tests can then be executed once the system is working. At any stage,

when a fault is discovered, it should be traced back to its cause and fixed, whereupon the testing system should go through the whole process, working its way back up to where the fault was found. Re-doing previous tests like this is called regression testing; its purpose is to ensure that changes do not break parts of the program that were already working. Because executing all these tests is tedious, it is important that an automated testing system be put in place to simplify this as much as possible. All the details of testing and how to perform it properly are beyond the scope of this module, but you need to be at least aware of its importance. Release is when the system is made available to end users. This is often done in three stages: alpha, beta and final release. Alpha releases are done early in the development process to allow key stakeholders to see how development is progressing and to try out important features of the system. The primary goal of an alpha release is to get feedback on particular features and to make changes as early as possible if they are necessary. Beta releases are done later in development but before the product is finished. These are made available to experienced users both to get feedback on features and to allow the system to be tested in a real environment and with unexpected input. A final release is when the system is made available either commercially for sale or it is installed for use in its normal environment with all users. Final release needs to consider how to migrate any data from existing systems so that it can be used in the new system. This phase also needs to consider how to move back to the old system if a catastrophic problem occurs and the new system becomes unusable. Final release should also have a plan for how to train users so that they can use the new system. Maintenance occurs after the final release. This is where changes are made to the existing system. There are three forms of maintenance. These involve fixing faults in the system, changing the system to cope with changes in its environment or modifying the system to perform new tasks. At least half of the maintenance effort is related to modifying systems to extend their functionality. Some view maintenance as an important phase of development, while others consider this to be the start of a new cycle of development where the development process is repeated, starting with the existing system as the base point. An important aspect of maintenance, and managing a normal development cycle, is dealing with change requests as they come in. Each change request must be recorded and prioritised. The cost of the change needs to be estimated and a decision made as to whether the change should occur and, if so, when. The stages described above, if followed linearly, would be what is sometimes called the traditional software development life cycle. In the textbook, this is called the Waterfall model of software development (figure 3.2). In practice, software development never progresses linearly through these stages. At a minimum, there is feedback when, at a later stage, issues are discovered that require reconsideration of what was done at a previous stage. This iterative approach to these stages is called the Waterfall with Iteration model of software development in the textbook (figure 3.4). The Waterfall and Waterfall with Iteration diagrams, as shown in the textbook, are commonly used examples of these models. Unfortunately, they do a disservice to Winston Royce, who originally described the Waterfall model of software development in 1970. His model originally included iteration and prototyping and was quite sophisticated for the time. (If you are interested you can read his original paper at: this is not required reading and is only provided for those who are interested in history.)

While it is necessary to start with analysis so that you understand the requirements and problem domain, it is not necessary to complete analysis before starting design. Once the key requirements and the core of the domain are understood, it is possible to start architectural design. Once the detailed requirements for a sub-system are understood, it is possible to start high-level and then detailed design for that sub-system. Design and implementation can be used to experiment with possible technical solutions or to prototype complex ideas in order to clarify aspects of analysis. There are several modern software engineering processes that take advantage of this overlapping of stages and that may occur to come up with very sophisticated development models. We will not explore these processes in detail, but it is important that you are aware that software development does not need to follow the linear approach that could be implied from a description of the development stages. During analysis, models are created to describe the systems requirements and to provide an abstract description of the system within its problem domain. These models are created to help both the end users and the developers to understand the problem they are working on. A key feature of OO development is that these models are then extended to create the design model. The design model just fills in details describing the structure of the system but in the same terms of the original analysis model. In traditional structured analysis and design, the analysis and design models were very different from each other, which made moving from analysis to design difficult. (Or, as Ed Yourdonone of the original founders of structured analysis and designsays, You perform the analysis and then a miracle occurs overnight and you do the design. (Yourdan, 2006)) Structured analysis and design also made it extremely difficult to use an iterative development model that required reconsidering the analysis model after starting design, because moving information between the models was very difficult. In OO development, moving between an analysis or design view is very fluid because the models are just more or less detailed. This makes it much easier to follow an iterative development model and to reconsider problems at a higher level of abstraction. CASE Tools Computer Aided Software Engineering (CASE) tools are used to assist developers during the software development process. There are many different types of CASE tools that can be used to assist with just about every stage of development, ranging from initial requirements capture through to implementation and testing. Some CASE tools are stand-alone tools that support one or just a few stages of development. Other tools are part of an integrated suite that can collaborate to support most stages of development. Currently, one of the more commonly used integrated suites is Rational Suite from IBM. It is not the only suite available, but it is most commonly known due to good marketing of the originating company (Rational) and their ties with some well-known methodologists. The goal of a CASE tool is to automate some aspects of software development. The most commonly used category of CASE tool is a configuration management tool. This type of tool keeps track of the different versions of documents and source code and provides a central repository where the most recent version can be accessed. It also provides a mechanism to backtrack and find any previous version of a document. As soon as there are a lot of files to manage or there are several people involved in working on files, a configuration management tool becomes very useful to ensure that people do not over-write each others work. In large projects, this is essential. One commonly used configuration management tool is Subversion (2006). (A lot of its popularity is due to its being freeware and used by most open-source projects.)

In relation to this module, there are a wide range of CASE tools that support OO analysis and design. These CASE tools support drawing the UML diagrams that make up the model of the system. The minimal support that you can expect is a drawing tool that provides templates for the different elements used in UML diagrams (Microsoft Visio is an example of this). What you should expect is that the tool will enforce the UML rules so that the diagram will be syntactically correct; most tools that call themselves CASE tools will provide this support. The next step up is a tool that can keep entities consistent across diagrams and also link parts of diagrams together to provide information about the model, not just simple diagrams. Finally, some tools can generate either shells of the source code or the complete source code from the data in the tool and can keep the diagrams up-to-date by reading data back in from the source code. Complete code generation from a CASE tool is not a panacea that eliminates the need for coding. What it means is that the detailed logical design information that would normally be written as source code has to be included in the diagrams and supporting text. As part of the Rational Suite, there is a tool called Rational Rose that supports OO analysis and design (IBM, 2007). We will not be using this tool in this module due to complexities in its licensing arrangements. The tool that we will use in this module is called astah*/community (2010). It is a freeware version of the tool that you can freely for this module and your own personal use. (Please see the license agreement at the astah* web site for complete details of allowed usage.) Consult the Syllabus software requirements section for instructions about downloading the software. astah* is written in Java, so it should run on just about any hardware and operating system environment that is less than five years old. Limitations of Object Technology People can sometimes have a silver bullet mentality. They want one thing that solves all their problems. Unfortunately, life is not so simple that one solution works for everything, including software development. An object-oriented approach has become the predominant approach to software development. This does not mean it is the only approach and that it should be applied to all problems. An important part of the early stages of analysis is to determine what approach will be used to solve the problem. In this module, we only deal with the OO approach because that is all that can be covered in one module. As a professional, you need to be aware of other approaches and know when the approaches you are familiar with are not appropriate. Two domains in particular for which OO approaches are not appropriate are simple database management and simple scientific programming. Interestingly, when you add enough complexity to either of these domains, OO approaches become more appropriate. In regards to simple database management, this is where you have structured data in a consistent format and where the application deals with just storing, retrieving and searching this data. In such cases, relational database management systems (RDBMS) are the appropriate tool to use. When you add complexity, such as where the records in the data become entities that your program manipulates, you may decide to add an OO layer to the system that performs this manipulation and then interfaces to the RDBMS for its data management functions. When the complexity increases to the point where the data is unstructured or in widely varying formats, you have probably reached the limits of RDBMS technology; you may then find that object-oriented database management systems (OODBMS) are useful, as they are particularly well suited to unstructured data. In scientific programming, when you are calculating the result of a formula, it may not be possible to identify meaningful objects for an OO approach. The formula itself becomes both 6

the only object in the program as well as the main function of the program. But as the program becomes more complex (e.g., the difference between calculating the maximum weight for the payload of a rocket and the control systems that manage inserting a satellite into orbit), you may find that OO approaches provide a way of controlling the complexity. Each formula can become its own object and the control systems become objects; they can interact with the appropriate formulas via the OO message passing mechanism. Development Problems Larry Constantine (the originator of structured analysis and design) makes the observation that software is peopleware (2001). It is developed by people to be used by people. This is the root cause of many problems that occur during software development. Software development requires that a group of people from different backgrounds interact to specify, design and build a software system. The game of Chinese whispers is a simple example of one reason why there are difficulties. In Chinese whispers, one person whispers a phrase to another person, and then the second person whispers it to a third, going around a circle until the last person whispers it back to the first person. Almost invariably there is very little similarity between the final phrase and the original phrase. The problem is that each person hears, interprets and restates the phrase. The same happens with a large development team. A potential user of the software system mentions a requirement, usually in general terms, to a colleague. The colleague then repeats this to a business analyst who repeats it to the other analysts on the project. They describe the requirement in some document that is then interpreted by a design team. The design team will then specify a design in a document that may be interpreted by a separate implementer. Then a tester may make their own independent interpretation of the requirement and decide whether it is implemented correctly in the software system. Each layer of communication increases the risk that information will be lost or embellished as new people try to understand what was originally requested. Some newer software development processes, including the Agile methods, emphasise minimal layers of communication by preferably having direct interaction between the end users and the developers. There are other organisational and technical problems that can occur, but interpersonal and communication issues seem to lead to the most problems in development. This module focuses on technical processes and techniques that are necessary in software development, but developers need to be aware of potential causes of problems and attempt to deal with them. Summary This module will examine the application of object-oriented analysis and design techniques across the breadth of the software development process. This week is an introduction to the general area of system development and the different tasks, techniques and tools used during development. The lecture wraps up with the warning that good techniques and tools are not a panacea, just an aid in building good systems. In the following weeks, we will look at the details of understanding a systems requirements and designing a feasible solution to meet those requirements. Reading The following readings provide the textbooks introduction to systems and development issues. Chapter 4 provides a review of OO concepts, which you should read as quickly or in as much depth as you require, depending on your comfort with OO concepts. Chapters A1 and B1 provide the background information that will be used in case study examples and exercises throughout this module. 7

From chapter 1, read sections 1.1, 1.2 (skipping boxes 1.2 and 1.3), 1.3, 1.4, skim 1.5, and read 1.6. From chapter 2, read sections 2.1, skim 2.2 and 2.3, read 2.4 to 2.6. From chapter 3, read sections 3.1, skim 3.2, read 3.3 to 3.6, skim 3.7 and read 3.8. If the lifecycle information presented in section 3.2 is unfamiliar, you should read this rather than skim it. From chapter 4, read sections 4.1, skim 4.2 and 4.3, skip the first part of 4.4 but read the subsection on Limitations of object-orientation, and read 4.5. If you feel a bit confused when skimming the material in section 4.2, you should read it in detail and review some of your material on OO concepts from a previous module. If, after doing this, you still feel lost in regards to OO concepts, you should contact your instructor to discuss your difficulties and to put a plan in place to catch up on this material. From chapters A1 and B1, read the introductions to the two case studies presented in the textbook. References Object Management Group (OMG) Inc. (2007) The object management group home page. [Online]. Available from: (Accessed: 5 January 2007). (UML) Object Management Group Inc. (2007) The unified modeling language resource page. [Online]. Available from: (Accessed: 5 January 2007). Yourdan, Ed (2006). Ed Yourdons professional home page. [Online]. Available from: (Accessed: 5 January 2007). The referenced quote is one that I (the module developer) have heard Ed Yourdon say, but I do not have a formal reference for it. This web site gives you a good background to an influential leader in the software development community, as well as his contact information if you want it. (Subversion) (2006). Subversion home page. [Online]. Available from: (Accessed: 5 January 2007). IBM (2007). Rational Suite. [Online]. Available from: (Accessed: 5 January 2007). astah* UML Modeling Tool (2010). astah*/community home page. [Online]. Available from: (Accessed: 9 May 2010). Constantine, Larry. (2001). The peopleware papers: Notes on the human side of software. Englewood Cliffs, NJ: Prentice Hall.