You are on page 1of 9

CIS339 Final Exam Review and Course Summary

The final exam consists of:

30 total questions, worth 230 pts: o 20 multiple choice questions at 6 points each o 10 Essay questions at 11 points each There are four pages in the exam Covers TCOs 1 8 Covers Chapters 1, 2, 4 - 9, 13, and 14

While all areas of the assigned text reading are fair game for the final exam, the following provides a summary of the key points you should remember concerning the weekly topics. Week 1 Reading: Chapter 1: Introduction to Systems Analysis and Design Reading: Chapter 2: Project Initiation Reading: Chapter 4: Requirements Determination

1. Planning.
Planning is the process of determining why a system should be built (project initiation) and defining the project management activities necessary to complete the project. In the planning phase the project manager will develop a schedule, staffing plan, cost estimate, and provide a consistent project structure that ensures that a working project environment is implemented.

2. Analysis.
Requirements Analysis is where the analysts will describe how the system should behave by eliciting and capturing the requirements for the system. Requirements specify the general functions, or services, a system should perform, capture users needs in terms of what the system should look like, and user expectations. The whole purpose behind the UML process is for us to be able to elicit, capture, and maintain requirements that are unambiguous, detailed, verifiable, consistent, modifiable, and traceable. If we strive to satisfy these quality criteria of requirements we will provide a solid foundation for the following development phases and minimize the risk of failing. The Analysis

phase produces documentation that specifies what the system shall do, without regards to actually how we will do it.

3. Design.
In the Design phase we determine how the system will satisfy the requirements that we specified in the Analysis phase. The Design process is an iterative process through which requirements are translated into a blueprint for the construction of the software. Design proceeds from a high level of abstraction and during this preliminary design we determine the general architecture of the system (i.e., the floor plan), the components (high level services) the different classes/objects (the decomposition of components into single minded classes), and the communication paths (the interfaces) between the different classes. We then refine the high level floor plan in the detailed design phase, where we take each of the individual class that we have specified and refine the class into detailed blueprints that can then be directly implemented in a programming language. The Design phase produces documentation that specifies how the system shall implement the requirements.

4. Implementation
In the implementation phase, we take the blueprints produced in the Design phase and build the system. As stated in the text, this phase concepts of (1) construction, (2) installation, and (3) support. The text discusses several Life Cycle models (1) Waterfall, (2) Rapid Application Development, and (3) Agile Development and a detailed description of these models is outside the scope of the discussion. However, one thing to remember is that all of these models go through the basic four life cycle development phases and the only difference between the models is the level of effort and sequencing of the phases and RUP is only one more model that implements the generic system development life cycle phases. So, all of the specific models perform planning, analysis, design, and implementation, but each model places different priorities and sequencing on the phases. Week 2 Reading: Chapter 5: Functional Modeling In week 2 the reading introduced you to the first steps of creating UML, which are to generate:

1. Activity diagrams 2. Use Case Descriptions 3. Use Case Diagrams


As we discussed in the class, the input to this activity is the system description, which is a textual based description that defines the different scenarios the business processes progress through. This system description is based on requirements that where elicited from the user through the various elicitation techniques (interviews, questionnaires, JAD session). The results of the elicitation process then become

the foundation for all subsequent activities, thus before you begin the elaboration activities that will define the system architecture and subsequent implementation details it is very important that you and the end user have agreed on the system description. Since if the system description is not valid, then no matter how well you perform the analysis and detailed design activities you will end up with a system that does not satisfy the end user. One final comment concerning the analysis steps described in the textbook. The textbook does a very good job in explaining and demonstrating each of the individual tasks. However, as we discussed in the discussion I do not feel that order in which the textbook is the best order of activities for the way I normally approach the problem. I do not want to imply the text is incorrect, but just that depending on how each person conceptualizes a problem the order of the three activities (Activity Diagram, Use Case Descriptions, Use Case Diagrams) can be done in any order.

Week 3 Reading: Chapter 6: Structural Modeling In Week 3 we extended the notion of object oriented analysis and design to structured modeling where the objective is to identify the pertinent Classes that make up the problem domain. Classes are the most important building block of any object-oriented system and each Class will describe a set of objects that share the same attributes, operations, and relationships. As the text describes, we use Classes to capture the vocabulary of the system under development. Defining the Structural Model of a system involves identifying the things that are important to the problem domain, but at the same eliminating the things that are not pertinent. It is these things, or Classes, that form the vocabulary of the system you are modeling. For example, if you are building a house things like walls, doors, windows, floors, and lights are some of the things that will be important to you when you model the house. However, when modeling the house you may not to worry about the landscaping, so the lawn, shrubs, fences would be things outside the boundary of the structural model (but they may well be as well). The important point is that when you begin identifying the Classes that make up your system it is important you identify only those things that are important to the problem at hand, and ignore those that are not. Otherwise, you will not have a well defined context, or boundary, to your problem and it will be very difficult to complete the analysis and design. As you begin to identify the things in your problem domain, you also identify the properties that are pertinent to each of the things. Properties are the characteristics we use to describe a particular object. For example, in the house example some of the properties that we use to describe a house are: 1. size in square footage 2. color 3. number of rooms

4. street address Now when we design a Class for our program we generate a list of operations or services that the class must perform. For example, in our house example, we will have to "paint" the walls and "vacuum the floor, so these are operations that we must perform. Then our programs will then implement these operations with a set of methods that specify explicit steps necessary to carry out the operations. That is, an operation is a logical thing that we as humans perform, and a method is the physical implementation of that operation. In addition, to identifying the things, properties, and operations we need to identify the relationships between the different things in the model. For example, individual walls, doors, and windows do not exist in isolation and we must determine how these things fit together. The types of relationships are:

1. Generalizationrelationship between a general thing, called the superclass or


parent, and a more specific thing called the subclass. For example, a house will have several types of doors but all the doors have some common characteristics. So, you define a superclass called door that contains the common attributes and operations (height, width, depth, open, close) then each specific type of door will be defined that inherits all the features of the door super class, but then specializes the definition to make it a specific type of door (fire door, French door, sliding door).

2. Aggregationrepresents whole/part relationship between different classes


that is one class (the aggregate class) is composed of other classes. For example, a room is an aggregate (or composition) of floors, walls, doors, and windows.

3. Associationis a relationship that specifics that objects of one thing are


connect to objects of another thing. That is, you can navigate from an object of one class to an object of another class, and vice versa. You use associations when you want to show a structural relationship, that is not an Aggregation or a Generalization. In the house example, an association between people and the house would be Person ---> Lives In ---> House The last concept we want to review is the idea of an object, which is defined as "a thing that can be seen or touched" (Websters) this implies the objects we create in our program physically reside in memory, which is necessary for us to manipulate them. Then any physical object must be created from some type of template, which is a Class, and an object is an instance of class thus the term instantiation. That is, a class is the blue print for an object--like a house blue print specifies how a house will be built, but a blue print is not an actual house, but only the design specifications for a house.

An object is the "instantiation" or creation of a Class based on Class specifications--like the house you live in was built using blue prints and your house is an instantiation of the blue prints and your specific house is only one instantiation of a house. If you live in a housing development you will see several houses built from the same set of blue prints. However, each house is

a different house object that is all based on the same blueprints, or class specifications.

A reference is how you identify and manipulate a specific object. For example, your house has an address that is used to send you mail, bill your telephone, water, electric etc. You can tell the difference between the houses in your development by their addresses. Thus, a Class specifies the structure and services that each object of that class will provide, an object is the physical instantiation of the Class, and a reference to an object allows us to manipulate a specific object. Then in order to allow our objects to provide the services in our programs we will construct operations that perform the services we need to accomplish. For example, our houses have laundry services, kitchen services, bathroom services etc. We then use attributes in a class definition to hold values that describe the physical object. In our house example, some attributes would be the house address and the color of the house. Then each house that we build will have specific values assigned to the attributes. For example, I build a house where the address = 1234 Evergreen Ave, with color = brown. I then build another house at addresses = 3456 Evergreen Ave with the color = pink. It is these specific attributes that set on house apart from another.

Finally, since objects do not exist in isolation, we determine the relationships between the different objects. There different types of relationships, associations, generalizations, and aggregations. These three relationships are the important ways in which things collaborate with another. In short: A class is the blue print for our objects An object is built from the specifications of a class Operations are the services we include in our classes that accomplish the processing. Properties are fields that hold attribute values that distinguish the different objects. Relationships identify how things interact with each other or how a thing is built using other objects. Week 4 Reading: Chapter 7: Behavioral Modeling In Week 4 we discussed interaction diagrams. Basically, an interaction diagram provides a story board that document the interaction of the objects in a scenario and the messages they pass between each other. As discussed in the reading, you

can model these story boards in two ways (1) emphasizing the time ordering of the messages using sequence diagrams or (2) emphasizing structural relationships among the objects that interact with communication diagrams. The sequence diagram is an interaction diagram that emphasizes the time ordering of the messages and there are two features that distinguish a sequence diagram from a communication diagram. First there is the object lifeline, which is the vertical dashed line that represents the physical existence of an object over time. The life line shows when objects are created and destroyed in the scenario, which is an important piece information when you move to lower levels of design. Second, a sequence diagram shows the focus of control, which shows which object in the scenario is controlling the execution of the application at a particular time. A communication diagram emphasizes the organization of the objects that participate in a scenario, without any time order message passing between the objects. This view allows you to see how two objects are linked by seeing what messages are passed, but there is no depiction of the transfer of control between the objects. This gives you a picture of the message passing in the context of the structural organization of objects that collaborate in a scenario, but does not depict the focus of control. So, two features distinguish a communication diagram from a sequence diagram. First, the links that indicate how one object is linked to another object is fully specified. Second, there is sequencing of the messaging between two objects that does not address transfer of control. Because sequence and collaboration diagrams derive the same information from the same UML functional and structural models, the sequence and collaboration diagrams are semantically equivalent, in that they show the same information, but with slightly different perspectives. It does not take much effort to take one diagram and convert it to the other without loss of information. However, keep in mind that communication diagrams show how the objects are linked, but the sequence diagram does not. On the other hand, a sequence diagram shows message passing and returns, but the communication does not. So, in both cases, the two diagrams show the same underlying model, but each diagram shows something the other does not. Week 5 Reading: Chapter 8: Moving to Design In the first five weeks of the course we have focused on classes and objects, which are the building blocks of the larger system. That is, classes are the lowest level building blocks of the system that are then integrated together to construct the complete functioning system. A typical software application may have 100's if not 1000's of individual classes and trying to understand a system just looking at the classes is a daunting, if not impossible tasks. You may have heard the old adage "you can't see the forest through the trees", which means that if you look at the details too closely then you will never seen how the constituent parts are combined to form the whole. This is true in object oriented systems as well since just looking at the classes provides a view that contains too much detail to understand the "big picture". In order for use to "see the forest", we need to take a step back and look at a higher level view and we do this by combining classes into packages. A package is a grouping structure that allows us to take a group of logically related classes and group them together into a higher level component. I have used the example of the house in several examples, and in a typical house (which is the

system) there are several room packages. The kitchen, garage, den, bedroom, bathroom, etc are all packages that group logically related objects. For example, the kitchen is made up of appliances, such as the microwave, dishwasher, refrigerator and each of these is then made up of smaller objects. We get a functioning appliance when we combine these objects, then a functioning kitchen when we combine all the appliances, then a functioning house when we integrate the houses. This iterative nature of integrating smaller components into larger ones in second nature to us as human being and is exactly what we do when we design our packages in our object oriented systems. Package diagrams are useful on large scale systems to get a "birds eye", or "big picture" view of the major elements in the system and their dependencies. If you think about it, every significant or complex "thing" in the world is constructed this way. In fact, the only way we are able to understand complex systems is to break the larger system into smaller chunks of components, which are then broken down into even smaller chunks until we can then say "hey, I know how to build that!" So, keep this in mind as you gain more experience with OOAD and I think you will find that the process will get easier each time you go through it. Week 6 Reading: Chapter 9: Method Design Chapter nine discusses the fundamentals of object oriented systems and some of the touted benefits of object-oriented design and programming that we will discuss are: Classes (abstract characterizations of objects) Inheritance (code sharing) Polymorphism (runtime binding of operations to objects) Improved maintenance Reusable code

Object-oriented analysis and design organizes software as a collection of discrete objects that incorporate both data and behavior (in structured programming--data structure and function are loosely connected). The four characteristics of an object oriented system are:

1. Identity.
Every object has an identity and data is put into discrete, distinguishable entities called objects. . Objects can be concrete, (e.g., file or a computer) or logical (e.g., scheduling policy in multiprocessing system, or a role in a process like a data entry clerk) Each object has its own distinct identity and two objects are distinct even if all the attribute values are identical. For example, two apples may look and feel the same, but they are two completely different objects and you can intuitively tell them about by looking at them. Finally, each object has a unique handle that is used to reference the object independent of content.

2. Classification
Objects with the same attributes and operations are grouped into a class and are an abstraction that describes properties and operations that satisfy the requirements of the applications. Then each object is an instance of its class and each instance has its own set of values for each attribute. A Class is the blue print for an object--like a house blue print specifies how a house will be build, but a blue print is not an actual house, but only the design specifications for a house. An object is the "instantiation" or creation of a Class based on Class specifications--like the house you live in was built using blue prints and your house is an instantiation of the blue prints and your specific house is only one instantiation of a house. If you live in a housing development you will see several houses built from the same set of blue prints. However, each house is a different house object that is based on the same blueprints, or class specifications.

3. Polymorphism
Polymorphism means the same operation may behave differently on different classes. For example, when someone says to you "lets go driving" a particular image comes to mind. However, if you say "lets go drive the car" a very specific implementation of driving is invoked. Now if you say "lets go drive the boat", or "lets go drive the motorcycle", in each case you are "logically" still driving but the implementation of "driving" in each case is different. 4. Inheritance Inheritance is the sharing of attributes and operations among classes and is based on hierarchical relationships. The parent class is defined broadly and then refined in finer subclasses. Each subclass inherits all of the properties of its superclass and then adds its own unique properties. When combining classes into packages we use the principle of functional independence (or connascence) to determine what classes should be grouped together. Functional independence is the concept where a component will perform a single minded function (do one thing only) and that the interaction with the other components is kept at a minimum. As the text describes there are two aspects to functional independence: cohesion--how single minded a component is coupling--how interdependent or interrelated the components are The bottom line is that if you always strive to maximize cohesion and minimize coupling then you will generate a system that is functionally independent, which implies that changes in one component will only have minimal effect in the dependent components. Also, functionally independent components are easier to replace, error propagation is kept at a minimum, and easier to test. Another mechanism to ensure that our components are functionally independent is to use develop a contract for each class, which specifies the public interface to the class and all external objects should be able to use a class by understanding the public interface, this hides all the details of the class which allows for greater reuse and reliability.

Once we determined the contracts, we need to specify the constraints on the each of the classes, that is what are the:

1. pre-conditionswhat must be true in order for the method to execute 2. post-conditionswhat will must be true after the method executes 3. class invariantsmust always be true for all instances of a class
Once the constraints have been identified, then we can generate the algorithm for each method, which then becomes the final blueprint for the programmer. Week 7 Reading Chapter 13: Construction Reading Chapter 14: Installation and Operations In week 7 we investigated program construction, installation, and operations. The lecture concentrated on the importance of construction since the final source program is, by definition, the most accurate specification of the final working program. We discussed the criteria to develop high quality methods and how self documenting code can greatly reduce the coding and maintenance activities.

You might also like