Spring 2012 Master of Computer Application (MCA) MC0069 System Analysis and Design (Book ID: B0714) Assignment

Set 1 (60 Marks)

Semester II 4 Credits

Book ID: B0714 Each question carries six marks 10 x 6 = 60 1. Explain the four basic principles of modeling. 2. How do you model template classes in the UML? Ans. In UML models, templates are model elements with unbound formal parameters that you can use to define families of classifiers, packages, and operations. A template is a parameterized model element that describes or identifies the pat tern for a group of model elements of a particular type. Because they represent types of elements, you cannot use templates directly in your models. Instead, yo u must first instantiate the template by binding its parameters to actual values . A binding between a template and a model element generates a new model element based on the template. You can then use the bound element to model part of a sy stem. Instead of designing distinct model elements for each data type in your model, y ou can use templates to design a single model element (a classifier, a package, or an operation) that works with different kinds of data. For example, a templat e class provides a parameterized description of a class, specifying its attribut es and operations. By binding multiple classes to the template you can generate new classes with the same characteristics as the template. A template appears as a classifier with a dashed box in the upper right corner. 3. Explain the significance of aggregation with an example. Ans. Aggregation is a specialize form of Association where all object have their own lifecycle but there is a ownership like parent and child. Child object can not belong to another parent object at the same time. We can think of it as "has -a" relationship. Implementation details: Typically we use pointer variables that point to an object that lives outsid e the scope of the aggregate class Can use reference values that point to an object that lives outside the scop e of the aggregate class Not responsible for creating/destroying subclasses Lets take an example of Employee and Company. A single Employee can not belong to multiple Companies (legally!! ), but if we d elete the Company, Employee object will not destroy. #include<iostream.h> class Employee { public: Employee(char *name){ cout<<"Employee::ctor\n";

myName_p = new char(sizeof(strlen(name))); myName_p = name; } char* disp(){return(myName_p);}; ~Employee() { cout<<"Employee:dtor\n\n"; delete (myName_p); } private: char *myName_p; }; class Company { public: Company(char * compName, Employee* emp){ cout<<"Company::ctor\n"; name = new char(sizeof(strlen(compName))); name = compName; myEmp_p = emp; }; ~Company() { cout<<"Company:dtor\n\n"; myEmp_p = NULL; }; private: char *name; Employee *myEmp_p; }; int main() { cout<<"\nExample of Aggregation Relationship \n"; cout<<"-----------------------------------------\n\n"; { cout<<"Here, an Employee-Keerti works for Company-MS \n"; Employee emp("Keerti"); { Company comp("MS", &emp); } // here Company object will be deleted, whereas Employee object is still t here cout<<"At this point Company gets deleted...\n"; cout<<"\nBut Employee-"<<emp.disp(); cout<<" is still there\n"; } //here Employee object will be deleted return(0); }

output: ------Example of Aggregation Relationship ----------------------------------------Here, an Employee-Keerti works for Company-MS Employee::ctor Company::ctor Company:dtor At this point Company gets deleted... But Employee-Keerti is still there Employee:dtor

4. Discuss UML s extensibility mechanisms. Ans. The extensibility mechanisms allow you to customize and extend the UML by a dding new building blocks, creating new properties, and specifying new semantics in or der to make the language suitable for your specific problem domain. There are three common extensibility mechanisms that are defined by the UML: stereotypes, tagged values, and constraints. 5. Give a brief note on the UML s five behavioral diagrams. Ans. Any system can have two aspects, static and dynamic. So a model is consider ed as complete when both the aspects are covered fully. Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic as pect can be further described as the changing/moving parts of a system. UML has the following five types of behavioral diagrams: Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Use case Diagram: Use case diagrams are a set of use cases, actors and their relationships. They r epresent the use case view of a system. A use case represents a particular functionality of a system. So use case diagram is used to describe the relationships among the functionalit ies and their internal/external controllers. These controllers are known as acto rs. Sequence Diagram: A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with some sequences, which are the sequence of messages flowing f rom one object to another. Interaction among the components of a system is very important from implementati

on and execution perspective. So Sequence diagram is used to visualize the sequence of calls in a system to pe rform a specific functionality. Collaboration Diagram: Collaboration diagram is another form of interaction diagram. It represents the structural organization of a system and the messages sent/received. Structural o rganization consists of objects and links. The purpose of collaboration diagram is similar to sequence diagram. But the spe cific purpose of collaboration diagram is to visualize the organization of objec ts and their interaction. Statechart Diagram: Any real time system is expected to be reacted by some kind of internal/external events. These events are responsible for state change of the system. Statechart diagram is used to represent the event driven state change of a syste m. It basically describes the state change of a class, interface etc. State chart diagram is used to visualize the reaction of a system by internal/ex ternal factors. Activity Diagram: Activity diagram describes the flow of control in a system. So it consists of ac tivities and links. The flow can be sequential, concurrent or branched. Activities are nothing but the functions of a system. Numbers of activity diagra ms are prepared to capture the entire flow in a system. Activity diagrams are used to visualize the flow of controls in a system. This i s prepared to have an idea of how the system will work when executed. 6. Explain the necessary steps to reverse engineer an object diagram. Ans. Various software tools provide support for reverse engineering, often based on UML design models. In UML tools,reverse engineering through static code anal ysis is typically restricted to class diagrams. The reverse engineering of seque nce diagrams through static analysis is the next logicalstep for these tools. Th e need to generate sequence diagrams from program code is important enough that a request to UML tool vendors to provide such advanced functionality is included in one popular book on modern software development . Some commercial modeling tools already incorporate reverse engineering of sequence diagrams (e.g., Togeth er ControlCenter by Borland and EclipseUML by Omondo). Reverse-engineered sequen ce diagrams can play a role in the maintenance of complex object-oriented system s. System evolution is often problematic in the absence of the original designers and developers due to incomplete or nonexistent design information. Reverse-engineered diagrams provide essential insig hts for software understanding of such systems. Sequence diagrams are also the basis of several approaches for testing of object-oriented software . These approaches test the interactions among coll aborating objects, and sequence diagrams can be used to identify the interaction s that must be covered. A coverage tool can employ static analysis to extract se quence diagrams from the tested code, and then use them to perform run-time cove rage analysis during the execution of the given test 7. Explain the terms context, objects and roles, links, messages 8. Explain the five parts of a transition. Ans. (a) System Study

System study is the first stage of system development life cycle. This gives a c lear picture of what actually the physical system is? In practice, the system st udy is done in two phases. In the first phase, the preliminary survey of the sys tem is done which helps in identifying the scope of the system. The second phase of the system study is more detailed and in-depth study in which the identifica tion of user s requirement and the limitations and problems of the present system are studied. After completing the system study, a system proposal is prepared by the System Analyst (who studies the system) and placed before the user. The pro posed system contains the findings of the present system and recommendations to overcome the limitations and problems of the present system in the light of the user s requirements. To describe the system study phase more analytically, we would say that system s tudy phase passes through the following steps: problem identification and project initiation background analysis inference or findings (b) Feasibility Study On the basis of result of the initial study, feasibility study takes place. The feasibility study is basically the test of the proposed system in the light of i ts workability, meeting user s requirements, effective use of resources and .of co urse, the cost effectiveness. The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy. (c) System Analysis Assuming that a new system is to be developed, the next phase is system analysis . Analysis involved a detailed study of the current system, leading to specifica tions of a new system. Analysis is a detailed study of various operations perfor med by a system and their relationships within and outside the system. During an alysis, data are collected on the available files, decision points and transacti ons handled by the present system. Interviews, on-site observation and questionn aire are the tools used for system analysis. Using the following steps it become s easy to draw the exact boundary of the new system under consideration: Keeping in view the problems and new requirements Workout the pros and cons including new areas of the system All procedures, requirements must be analysed and documented in the form of deta iled data flow diagrams (DFDs), data dictionary, logical data structures and min iature specifications. System Analysis also includes sub-dividing of complex pro cess involving the entire system, identification of data store and manual proces ses. The main points to be discussed in system analysis are: Specification of what the new system is to accomplish based on the user requ irements. Functional hierarchy showing the functions to be performed by the new system and their relationship with each other. Function network which are similar to function hierarchy but they highlight the those functions which are common to more than one procedure. List of attributes of the entities - these are the data items which need to be held about each entity (record)

(d) System Design Based on the user requirements and the detailed analysis of a new system, the ne w system must be designed. This is the phase of system designing. It is a most c rucial phase in the development of a system. Normally, the design proceeds in tw o stages : preliminary or general design Structure or detailed design Preliminary or general design: In the preliminary or general design, the feature s of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated. If the project is still considered to be feasible, we move to the detailed design stage. Structure or Detailed design: In the detailed design stage, computer oriented wo rk begins in earnest. At this stage, the design of the system becomes more struc tured. Structure design is a blue print of a computer system solution to a given problem having the same components and inter-relationship among the same compon ents as the original problem. Input, output and processing specifications are dr awn up in detail. In the design stage, the programming language and the platform in which the new system will run are also decided. There are several tools and techniques used for designing. These tools and techn iques are: Flowchart Data flow diagram (DFDs) Data dictionary Structured English Decision table Decision tree Each of the above tools for designing will be discussed in detailed in the next lesson. (e) Coding After designing the new system, the whole system is required to be converted int o computer understanding language. Coding the new system into computer programmi ng language does this. It is an important stage where the defined procedure are transformed into control specifications by the help of a computer language. This is also called the programming phase in which the programmer converts the progr am specifications into computer instructions, which we refer as programs. The pr ograms coordinate the data movements and control the entire process in a system. It is generally felt that the programs must be modular in nature. This helps in fast development, maintenance and future change, if required. (f) Testing Before actually implementing the new system into operations, a test run of the s ystem is done removing all the bugs, if any. It is an important phase of a succe ssful system. After codifying the whole programs of the system, a test plan shou ld be developed and run on a given set of test data. The output of the test run should match the expected results. Using the test data following test run are carried out: Unit test

System test Unit test: When the programs have been coded and compiled and brought to working conditions, they must be individually tested with the prepared test data. Any u ndesirable happening must be noted and debugged (error corrections). System Test: After carrying out the unit test for each of the programs of the sy stem and when errors are removed, then system test is done. At this stage the te st is done on actual data. The complete system is executed on the actual data. A t each stage of the execution, the results or output of the system is analysed. During the result analysis, it may be found that the outputs are not matching th e expected out of the system. In such case, the errors in the particular program s are identified and are fixed and further tested for the expected output. When it is ensured that the system is running error-free, the users are called w ith their own actual data so that the system could be shown running as per their requirements. (g) Implementation After having the user acceptance of the new system developed, the implementation phase begins. Implementation is the stage of a project during which theory is t urned into practice. During this phase, all the programs of the system are loade d onto the user's computer. After loading the system, training of the users star ts. Main topics of such type of training are: How How How How to to to to execute the package enter the data process the data (processing details) take out the reports

After the users are trained about the computerised system, manual working has to shift from manual to computerised working. The following two strategies are fol lowed for running the system: Parallel run: In such run for a certain defined period, both the systems i.e . computerised and manual are executed in parallel. This strategy is helpful bec ause of the following: Manual results can be compared with the results of the computerised syst em. Failure of the computerised system at the early stage, does not affect t he working of the organisation, because the manual system continues to work, as it used to do. Pilot run: In this type of run, the new system is installed in art of the new system is installed first and executed successfully ble time period. When the results are found satisfactory then only re implemented. This strategy builds the confidence and the errors sily. (h) Maintenance Maintenance is necessary to eliminate errors in the system during its working li fe and to tune the system to any variations in its working environment. It has b een seen that there are always some errors found in the system that must be note d and corrected. It also means the review of the system from time to time. The r eview of the system is done for: knowing the full capabilities of the system parts. Some p for considera other parts a are traced ea

knowing the required changes or the additional requirements studying the performance If a major change to a system is needed, a new project may have to be set up to carry out the change. The new project will then proceed through all the above li fe cycle phases. 9. Explain the 3 steps to be considered to model an API. Ans. There are three steps involved in validating a model: Validate the model fields Validate the model as a whole Validate the field uniqueness All three steps are performed when you call a model s full_clean() method. When you use a ModelForm, the call to is_valid() will perform these validation s teps for all the fields that are included on the form. See the ModelForm documen tation for more information. You should only need to call a model s full_clean() m ethod if you plan to handle validation errors yourself, or if you have excluded fields from the ModelForm that require validation. Model.full_clean(exclude=None) This method calls Model.clean_fields(), Model.clean(), and Model.validate_unique (), in that order and raises a ValidationError that has a message_dict attribute containing errors from all three stages. The optional exclude argument can be used to provide a list of field names that can be excluded from validation and cleaning. ModelForm uses this argument to ex clude fields that aren t present on your form from being validated since any error s raised could not be corrected by the user. Note that full_clean() will not be called automatically when you call your model s save() method, nor as a result of ModelForm validation. You ll need to call it ma nually when you want to run one-step model validation for your own manually crea ted models. 10. Explain the importance of models.

Spring 2012 Master of Computer Application (MCA) Semester II MC0069 System Analysis and Design 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks) Book ID: B0714 Each question carries six marks 10 x 6 = 60 1. Explain the four kinds of relationships in UML. Ans. UML supports 4 different relationships. They are: Dependency The dependency relationship between two entities means that one e ntity is dependent on another. The entity which depends on another is called the dependent entity and the other entity is called as independent entity. When the re are any changes in independent entity, then it may affect the dependent entit y, but the vice versa is not applicable. Dependency is denoted in UML as dotted

line with a directed arrow from dependent entity to independent entity. Association Association is a relationship that enforces communication betwee n any two objects. Association is denoted in UML by a solid line with a label in dicating a relevant name for the relationship. Generalization Generalization refers to the inheritance relationship where t he attributes and behavior of the super (parent) class is inherited by the sub ( child) class. Generalization in UML is denoted by solid line followed by a trian gular arrow. The arrow will be directed from the child class to the parent class . Realization Realization is a special relationship that occurs between classi fiers wherein one classifier will specify a contract and the other classifier ca rries out the semantics of the contract. For example realization is the relation ship between an interface and the class that implements the interface. Realizati on is denoted in UML as a dotted line followed by a triangular arrow.

2. What are the considerations that should be taken care to model the distributi on of responsibilities in a system? 3. Explain dependency in detail and also how is it different from dependency. 4. Define stereotype, tagged value and constraint. Ans. Stereotype is a profile class which defines how an existing metaclass may b e extended as part of a profile. It enables the use of a platform or domain spec ific terminology or notation in place of, or in addition to, the ones used for t he extended metaclass. A stereotype cannot be used by itself, but must always be used with one of the m etaclasses it extends. Stereotype cannot be extended by another stereotype. A stereotype uses the same notation as a class, with the keyword stereotype shown before or above the name of the stereotype. Stereotype names should not clash wi th keyword names for the extended model element. Servlet Stereotype extends Component. Stereotype can change the graphical appearance of the extended model element by using attached icons represented by Image class. Stereotype Servlet with attached custom icon. Actor is extended by stereotype Web Client with attached custom icon. Because stereotype is a class, it may have properties. Properties of a stereotyp e are referred to as tag definitions. When a stereotype is applied to a model el ement, the values of the properties are referred to as tagged values. Device extended by Server stereotype with tag definitions and custom icon. Tagged Value: UML 1.x defined tagged value as one of UML extensibility mechanisms permitting a rbitrary information (which could not be expressed by UML) to be attached to mod els. Tagged value is a keyword-value pair that may be attached to any kind of mo del element. The keyword is called a tag. Each tag represents a particular kind of property a pplicable to one or many kinds of model elements. Both the tag and the value are usually encoded as strings though UML tool allow to use other data types for va lues. Tagged value specification in UML 1.x has the form name = value where name is the name of a tag or metamodel attribute and value is an arbitrary string that denotes its value. For example, {author="Joe Smith", deadline=31-March-1997, status=analysis} Boolean tags frequently have the form isQuality, where quality is some condition that may be true or false. In these cases, the form "quality" may usually appea r by itself, without a value and defaulting to true. For example, {abstract} is the same as {isAbstract=true}. To specify a value of false, omit the name comple tely. Tags of other types require explicit values.

Tagged value (as well as metamodel attribute) is displayed as a comma delimited sequence of properties inside a pair of curly braces "{" and "}". Stereotype Computer applied using "traditional" tag values notation. In UML 1.3 tagged values could extend a model element without requiring the pres ence of a stereotype. In UML 1.4, this capability, although still supported, was deprecated, to be used only for backward compatibility reasons. Since UML 2.0, a tagged value can only be represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in or der to be extended by tagged values. To support compatibility with the UML 1.3 s ome UML tools can automatically define a stereotype to which "unattached" attrib utes (tagged values) will be attached. Tag values could be shown in class compartment under stereotype name. An additio nal compartment is required for each applied stereotype whose values are to be d isplayed. Each such compartment is headed by the name of the applied stereotype in guillemets. Stereotype Computer applied with tag values in compartment Tag values could be shown in attached comment under stereotype name. Stereotype Computer applied with tag values in comment note When displayed in compartments or in a comment symbol, each name-value pair shou ld appear on a separate line. Constraint: A constraint is used to express a condition, restriction or assertion related to some of the semantics of a model element. Constraint is a condition which must evaluate to true by a correct design of the system. For example, bank account balance constraint could be expressed as: {balance >= 0} Constraint in UML is usually written in curly braces using any computer or natur al language including English, so that it might look as: {account balance is positive} UML prefers OCL as constraint language. 5. What is the main advantage of modeling a system at different levels of abstra ction by presenting diagrams with different levels of detail? 6. Explain the process of modeling a logical database schema? Ans. Logical modeling deals with gathering business requirements and converting those requirements into a model. The logical model revolves around the needs of the business, not the database, although the needs of the business are used to e stablish the needs of the database. Logical modeling involves gathering informat ion about business processes, business entities (categories of data), and organi zational units. After this information is gathered, diagrams and reports are pro duced including entity relationship diagrams, business process diagrams, and eve ntually process flow diagrams. The diagrams produced should show the processes a nd data that exists, as well as the relationships between business processes and data. Logical modeling should accurately render a visual representation of the activities and data relevant to a particular business. The diagrams and documentation generated during logical modeling is used to dete rmine whether the requirements of the business have been completely gathered. Ma nagement, developers, and end users alike review these diagrams and documentatio n to determine if more work is required before physical modeling commences. Typical deliverables of logical modeling include Entity relationship diagrams An Entity Relationship Diagram is also referred to as an analysis ERD. The p oint of the initial ERD is to provide the development team with a picture of the different categories of data for the business, as well as how these categories of data are related to one another. Business process diagrams The process model illustrates all the parent and child processes that are pe

rformed by individuals within a company. The process model gives the development team an idea of how data moves within the organization. Because process models illustrate the activities of individuals in the company, the process model can b e used to determine how a database application interface is design.

7. Explain the concept of sequencing. 8. Explain the different components of states with reference to state machines. 9. Explain behavioral aspects of collaboration with an example. 10. Explain with a neat diagram how you would model the architecture of a system .