ITM 305 NOTES. Week 2: Chapter 1: introduction to systems development SDLC. Information systems development process.

Size: px
Start display at page:

Download "ITM 305 NOTES. Week 2: Chapter 1: introduction to systems development SDLC. Information systems development process."

Transcription

1 ITM 305 NOTES Week 2: Chapter 1: introduction to systems development SDLC Information systems development process Agile development Neither team members nor the user completely understands the problems and complexities of a new system Be responsive to unanticipated issues Agile and flexible Allow, anticipate, embrace changes and new requirements during development process Iterative development grown in an organic fashion Piece by piece Core components developed first, additional components are added One big project, with many mini-projects Week 2: Chapter 8: Approaches to System Development Predictive approach to the SDLC Can be planned and organized New information system can be developed according to the plan Phases o Project initiation o Project planning o Analysis o Design o Implementation o Deployment o support Waterfall model o Assumes phases can be carried out and completed sequentially o No going back o Rigid planning, final decision-making at each step Adaptive approach Assumes project must be more flexible and adapt to changing needs as project progresses System requirements needs aren t well understood Cant be planned completely

2 Spiral model o Some analysis, some design, some implementation o More analysis, more design, more implementation o Even more analysis, even more design, even more implementation Incremental Based on iterative life cycle System is built in small increments Walking skeleton Provides complete front to back implementation of the new system but with only bare bones of functionality Later adds flesh Gets working software into hands of the user early Extensive user texting and feedback Iterative is also adaptive Predictive waterfall includes a support phase but adaptive and iterative SDLCs don t System development methodology Set of comprehensive guidelines for SDLC Includes models, tools, techniques Models Record or communicate information Representation of an important aspect of the real world o Inputs, outputs, processes, data, objects, object interactions, locations, networks, devices o Gantt chart Tools Software support that helps create models or other components required in the project Integrated development environments Includes many tools to help with programming Smart editors, context-sensitive help, debugging tool Visual modeling tools Techniques Collection of guidelines that helps an analyst complete an activity or task Step by step instructions for creating a model Advice

3 Methodology includes a collection of techniques that are used to complete activities Within each phase of the systems development life cycle. The activities Include the completion of a variety of models as well as other documents and Deliverables. Like any other professionals, system developers use software tools to help them complete their activities. Software construction and modeling Structured approach o For predictive approach o Programming approach where each module has one start/end point, uses sequence, decision, repetition constructs only Top-Down Programming o Divides complex program into hierarchy of modules Structure design, chart, analysis o Loosely coupled o Highly cohesive o Easier to understand what each modules does and whether it affects the outcome of any other modules Data flow diagram Object oriented approach o Collection of interacting objects that work together to accomplish tasks Chaordic (chaos and order) Week 3: Chapter 9: Project Planning and Project Management Finishing on time, within budget, effectively meet the need Oversight committee clients and key managers who review the progress and direct the project Ceremony -level of formality of the project PMI(Project Management Institute) Agile Project Management (APM) PMBOK (Project Management Body of Knowledge Project scope management Time Cost Quality Human resource Communications

4 Risk Procurement Integration System vision document (scope) Problem description Anticipated business benefits System capabilities Business benefits contains the results that the org. anticipates it will accrue from a new system System capabilities support the realization of the beliefs, helps identify the size and complexity of the new system and project that will be required Net present value Payback period Tangible benefit Intangible benefit Determine project risk and feasibility, review with client and obtain approval Establish project environment, schedule work, staff and allocate resources Evaluate work processes, monitor, make corrections Week 3: Chapter 2: Investigating System Requirements Technology architecture The set of computing hardware, network hardware, and topology, and system software employed by the org. Application architecture The info systems that supports the org. (info systems, subsystems, and support tech) Consolidated Sales and Marketing System (CSMS) Goal is to modernize technology and functionality Add more customer-oriented functionality Four subsystems o Sales subsystem o Order fulfillment subsystem o Customer account subsystem o Marketing subsystem System analysis activities Gather detailed information

5 Define requirements Prioritize requirements Develop user-interface dialogs Evaluate requirements with users System requirements the activities a system must perform or support and the constraints that the system must meet Separate into functional/non-functional requirements Functional requirements the activities that the system must perform Business functions the users carry out, use cases Non-functional requirements characteristics of the system other than those activities it must perform or support Constraints and performance goals To differentiate functional and non-functional use FURPS Functional requirements Usability requirements Reliability requirements Performance requirements Security requirements Model - representation of some aspect of a system Textual models something written down, describes requirements, detailed Graphical models use pictures for graphs, layouts, maps

6 Mathematical models - -use numbers, formulas, algorithms Unified Modeling Language (UML) standard set of model constructs and notations defined by the Object Management Group Stakeholders ppl w/ interest in successful implementation of system Internal (persons inside org.) External (persons outside org.) Operational (regularly interact w/ system) Executive (use the info for financial interest) Gathering information Interviews w/ users and stakeholders Distribute and collect questionnaires Review inputs, outputs, and documentation Observe and document business procedures Research vendor solutions Collect active user comments and suggestions Documenting workflows with activity diagrams Workflow sequence of processing steps that completely handles one business transaction or customer request Activity diagram describes user/system activities, sequential flow Week 4: Chapter 3: Use Cases Use case an activity that the system performs, usually in response to a request by a user User goal technique o Determines what specific goals/objectives must be completed by a user Identify all potential users Classify potential users in terms of their functional role Classy potential users by organizational level Identify their goals Organize use cases by type of user Look for duplicates/inconsistencies Identify where different types of users need same use cases Review Event decomposition technique o Determines the external business events to which the system must respond External event Temporal event State event o Event vs sequence of prior conditions to an event

7 o Perfect technology assumption External events to look for include: External agent wants something resulting in a transaction External agent wants some information Data changed and needs to be updated Management wants some information Temporal events to look for include: Internal outputs needed Management reports (summary or exception) Operational reports (detailed transactions) Internal statements and documents (including payroll) External outputs needed Statements, status reports, bills, reminders For state events, what will the system respond to, internal state changes trigger use cases Do not use events that involve login, logout, change pass, backup, restore CRUD (create, read, update, delete) archive Technique to validate, refine, cross-check use cases o Identify all data entities/domain classes involved in new system o Verify that a use case has been identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes an instance Use Case Diagram Steps Identify all stakeholders and users who would benefit by seeing a use case diagram Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use cases that are of interest For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users Week 5: Chapter 5: Extending the Requirements Model Use Case Diagram lists and describes the processing details of a use case Use case name Scenario Triggering event Brief description Actors Related use cases Stakeholders

8 Preconditions Post conditions Flow of activities Exception conditions Scenarios/ use case instances Interaction diagram shows interaction between actors and objects within the system System Sequence Diagram (SSD) showing the sequence of messages b/w an external actor and the system during a use case /scenario UML sequence diagram (unified modeling language) SSD Notation Lifeline Loop frame True/false condition Opt frame (based on true/false condition) alt frame (if/then else condition) Developing SSD 1. identify input message 2. describe message from external actor to the system using message notation 3. identify special conditions on input messages 4. identify and add output return values State Machine Diagram shows the life of an object in states and transitions state transition action expression pseudo state (starting point) origin state destination state guard condition Concurrent states Composite states Concurrent Paths (multiple paths in concurrent states)

9 Developing State Machine Diagram 1. review the class diagram, select classes that might require state machine diagrams 2. make list of status conditions 3. identify transitions 4. sequence the states in correct order 5. review paths and look for independent concurrent paths 6. look for additional transitions, test both directions 7. expand each transition with appropriate message event, guard condition, action expression 8. review and test state machine diagram MIDTERM Chapter 4: Domain Classes Problem domain The specific area of the user s business need that is within the scope of the new system Things (domain classes) Those items users work with when accomplishing tasks that need to be remembered Products, sales, shippers, customers, invoices, payments Brainstorming Technique Use checklist of all usual types of things typically found and brainstorm to identify domain classes of each type

10 Steps 1. Identify user & set of use cases 2. Brainstorm to identify things involved when carrying out the use case which information should be captured by the system. 3. Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember? Noun Technique Identify all nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember finding, classifying, refining a list of nouns that come up in discussions or documents Popular, systematic Ends up with long lists + many nouns that may not be used Difficult identifying synonyms and things that are really attributes Good place to start when there are no users available to help brainstorm Steps 1. Using the use cases, actors, and other information about the system including inputs and outputs identify all nouns. For the RMO CSMS, the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation 2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed. For the RMO CSMS, these might include price, size, color, style, season, inventory quantity, payment method, and shipping address.

11 Details about Domain Classes Attribute one piece of information about each instance of the class o Customer has first name, last name, phone number Identifier or key one attribute that uniquely identifies an instance of a class, required for data entities, optional for domain classes Compound attribute two or more attributes combined into one structure to simplify the model o Address rather than number, street, city, state, zip separately CLARIFICATION! Called association on class diagram in UML o Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many o We are emphasizing UML in this text Called relationship on ERD in database class o Cardinality is term for number of relationships in entity relationship diagrams: 1 to 1 or 1 to many Associations and Relationships apply in two directions o Read them separately each way o A customer places an order o An order is placed by a customer Minimum & Maximum Multiplicity Associations have minimum & maximum constraints o If mini = 0, association is optional o If mim > 1, association is mandatory Types of Associations Binary association o Two diff classes Course section includes students Members join club Unary association (recursive) o b/w 2 instances of the same class person married to person part is made using parts ternary association (three)

12 n-ary association (b/w n) Semantic Net shows instances and how they are linked The Domain Model Class Diagram class o category of classification used to describe a collection of objects domain class o classes that describe objects in the problem domain class diagram o a UML diagram that shows classes with attributes and associations (plus methods if it models software classes) domain model class diagram o a class diagram that only includes classes from the problem domain, not software classes so no methods Domain Class Notation domain class has no methods class name is always capitalized attribute names are not capitalized and use camelback notation

13 More Complex Issues about Classes generalization/specialization o a hierarchical relationship where subordinate classes are special types of superior classes superclass o the superior or more general class in a generalization/specialization hierarchy subclass o the subordinate or more specialized class in a generalization/specialization hierarchy inheritance o the concept that subclasses inherit characteristics of the more general superclass More Complex Issues about Classes: Whole Part Relationships Whole-part relationship a relationship between classes where one class is part of or a component portion of another class Aggregation a whole part relationship where the component part exists separately and can be removed and replaced (UML diamond symbol, next slide) o Computer has disk storage devices o Car has wheels

14 Composition a whole part relationship where the parts can no longer be removed (filled in diamond symbol) o Hand has fingers o Chip has circuits Three types of UML Relationships Association Relationships Whole Part Relationships Generalizations/Specialization Relationships o inheritance Entity Relationship Diagrams CARDINALITY SYMBOLS An ERD shows basically the same information as a domain model class diagram It is not a UML diagram, but it is widely used by data analysts in database management There really is no standard notation, but most developers use the entity and crows feet notation shown in this text An ERD is not good for showing generalization/specialization relationships and whole part relationships

15 Ch 10: Object-Oriented Design: Principles OO design: process by which a set of detailed OO design models are built to be used for coding Design models are created in parallel to actual coding/implementation w/ iterative SDLC Agile approach says create models only if they are necessary Simple detailed aspects don t need a design model before coding UML Requirements vs Design Models o Diagrams are enhanced and extended Architectural design o Enterprise level system A system that has shared resources among multiple people or groups in an organization o Options are client-server or internet based Each presents different issues Component diagram o Type of design diagram that shows the overall system architecture and the logical components within it for how the system will be implemented o Identifies logical, reusable, transportable system components that define system architecture o Essential element of a component diagram is the component element with its API o Application program interface (API) o The set of public methods that are available to the outside world Detailed design (use case realization) o Design and implement use case by use case Sequence diagram extended SSD w/ added controller + domain classes

16 Design class diagram extend from domain model class diagram and update from sequence diagram class definition written in the chosen code for the controller and the design classes UI classes forms/pages are added to handle user interface b/w actor + controller Data Access Classes added to handle domain layer requests to get/save data to the database Design Classes in Detailed Design o Elaborate attributes visibility, type, properties o Add methods + complete signatures OO Detailed Design Steps Design Class Diagrams o Stereotype way of categorizing a model element by its characteristics, indicated by guillemots (<<>>) o Persistent class class whose objects exist after a system is shut down (date remembered) o Entity class design identifier for a problem domain class (usually persistent) o Boundary class/view class class that exists on a system s automation boundary, such as an input window for, or web page o Control class class that mediates b/w boundary classes and entity classes acting as switchboard b/w view layer and domain layer o Data access class class that is used to retrieve data from and send data to a database Class Stereotypes in UML

17 Notation for a Design Class (syntax for name, attributes, methods) Notation for Design Classes o Attributes Visibility ( + not public or - private) whether attribute can be accessed directly by another object Attribute name lower case camelback notation Type expression class, string, integer, double, date Initial value if applicable the default value Property if applicable, such as {key} Ex: - accountno: String {key} -startingjobcode: integer = 01 o Methods o Visibility indicates (+ or -) whether an method can be invoked by another object. Usually public (+), can be private if invoked within class like a subroutine

18 o Method name Lower case camelback, verb-noun o Parameters variables passed to a method o Return type the type of the data returned o Examples: +setname(fname, lname) : void (void is usually let off) +getname(): string (what is returned is a string) -checkvalidity(date) : int (assuming int is a returned code) Notation for Design Classes o Class level method applies to class rather than objects of class (static method) is underlined +findstudentsabovehours(hours): Array +getnumberofcustomers(): Integer o Class level attribute applies to the class rather than an object (aka static attribute). Underline it. -noofphonesales: int o Abstract class class that can t be instantiated. o Only for inheritance. Name in Italics. o Concrete class class that can be instantiated. Notation for Design Classes (method arguments and return types not shown) Notation for Design Classes (navigation visibility) o Ability of one object to view + interact w/ another object o Accomplished by adding an object reference variable to a class o Shown as arrow head on association line

19 o Navigation Visbility Guidelines o One-to-many associations indicate a superior/subordinate relationship are usually navigated from superior to subordinate o Mandatory associations, objects in one class cant exist w/o objects of another class, usually navigated from more independent class to dependent o When object needs info from other object, navigation arrow might be required o Navigation arrows may be bidirectional First Cut Design Class Diagram o proceed use case by use case, adding to diagram o pick domain classes that are involved in use case (see pre/post conditions for ideas) o add controller class to be in charge of use case o determine initial navigation visibility requirements using guidelines + add to diagram o elaborate attributes of each class w/ visibility + type o note that often the associations and multiplicity are removed from the design class diagram as in text to emphasize navigation, but are often left on designing w/ CRC cards (classes, responsibilities, collaboration cards) OO design is about assigning Responsibilities to Classes for how they Collaborate to accomplish a use case Usually a manual process done in a brainstorming session o 3 x 5 note cards o One card per class o Front has responsibilities + collaborations o Back has attributes needed CRC Cards Procedure o Process is design/realize a single use case, start w/ unused CRC cards, add a controller class o Identify problem domain class w/ primary responsibility for this use case that will receive the first message from the use case controller o Use first cut design class diagram to identify other classes that must collaborate w primary object class to complete use case o Have use case descrips and SSDs handy o Start w/ class that gets first message from controller, name responsibility o What does first class needs to carry out responsibility, assign other classes responsibilities to satisfy each need

20 o o Add collaborators to cards showing which collaborate with which, add attributes to back when data is used Eventually add user interface classes or data access classes o o Fundamental Design Principles o Coupling Quantitative measure of how closely related classes are linked (tightly/loosely coupled) Two classes are tightly coupled if there are lots of associations with another class Two classes are tightly coupled if there are lots of messages to another class Best to have loosely coupled o Cohesion Quantitative measure of focus/unity of purpose w/in single class (high/low cohesiveness) One class has high cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class (a customer carries out responsibilities that naturally apply to customers) One class has low cohesiveness if its responsibilities are broad or makeshift Best to have highly cohesive

21 o o o Protection from Variations Design principle that states parts of system unlikely to change are separated (protected) from those that will surely change Separate user interface forms + pages likely to change from application logic Put database connection + SQL logic that is likely to change in a separate classes from app logic Use adaptor classes that are likely to change when interfacing w/ other systems Better to choose one w/ protection from variations Indirection A design principle that states an intermediate class is placed between two classes to decouple them but still link them A controller class between UI classes and problem domain classes is an example Supports low coupling Indirection is used to support security by directing messages to an intermediate class as in a firewall If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security Object responsibility A design principle that states objects are responsible for carrying out system processing A fundamental assumption of OO design and programming Responsibilities include knowing and doing Objects know about other objects (associations) and they know about their attribute values. Objects know how to carry out methods, do what they are asked to do. Note that CRC cards and the design in the next chapter involve assigning responsibilities to classes to carry out a use case. If deciding between two alternative designs, choose the one where objects are assigned responsibilities to collaborate to complete tasks (don t think procedurally). Chapter 11: Object Oriented Design: Use Case Realizations Discussion of OO software design at more advanced lvl 3 layer design uses sequence diagrams, communication diagrams, package diagrams, and design patterns Design is shown to proceed use case by use case, and w/in each use case, layer by layer Detailed Design of Multilayer Systems o CRC cards focus on business logic (problem domain layer of classes) o Include view layer, business logic/problem domain layer, data access layer How do objects get created in memory? How does the user interface interact with other objects?

22 How are objects handled by the database? Will other objects be necessary? What is the lifespan of each object? Design Patterns standard design technique + template popular o Pattern name o Problem that requires solution o Pattern that solves problem o Example of pattern o Pros + cons Controller pattern o problem: how to handle all messages from view layer to classes in problem domain layer to reduce coupling o Sol: assign one class b/w view layer + problem domain layer that receives all messages + acts as switchboard directing messages to problem domain Use case realization w/ sequence diagrams - process of elaborating detailed design of use case w/ interaction diagrams o UML sequence diagrams o UML comm. Diagram o Sequence diagrams (use case realization sequence diagrams), extend the system sequence diagram (SSD) to show: View layer objects Domain layer objects Data access layer objects Assumptions o Perfect technology assumption o Perfect memory assumption o Perfect solution assumption o Separation of responsibilities Developing a Multilayer Design o View layer (Forms, pages) Data Access Layer o Persistent classes need mechanism for storing + retrieving state from a database o Separate layer required when business logic is complex Updating Design Classes o Focusses on domain layer o When object of a class receives a message, that message becomes a method in the class on the DCD Implementation Issues (3 layer design) o View layer class responsibilities Display electronic forms and reports Capture such input events as clicks, rollovers, key entries Display data fields Accept input data Edit/validate input data

23 Forward input data to domain layer classes Start/shut down system o Domain layer class responsibilities Create problem (persistent) classes Process all business rules w/ appropriate logic Prepare persistent classes for storage to the database o Data access layer class responsibilities Establish and maintain connections to database Contain all SQL statements Process result sets into appropriate domain objects Disconnect gracefully from database More design patterns o Adapter Like an electrical adapter Lace an adapter class b/w your system and an external system

24 o Factory Use factor class when creation logic is complex for a set of classes

25 o Singleton Use when only one instance should exist at a time and is shared

26 Chapter 13: Operational implementation includes programming and testing activities deployment includes system tests, converting data, training, setting up production environment, deploying solution testing process of examining a component, subsystem, or system to determine its operational characteristics and whether it contains any defects test case a formal description of a starting state, one or more events to which system responds to and expected response/end state

27 test data- set of starting states and events used to test a module, group of modules, or entire system unit testing o unit test tests of an individual method, class, component before it is integrated w/ other software o driver- method/class developed for unit testing that stimulates behaviour of method that sends a message to method being tested o stub method/class developed for unit testing that simulates the behaviour of a method invoked that hasn t yet been written integration testing o tests of a behaviour of a group of methods, classes, components interface incompatibility (one method passes parameter of wrong data type to another method) parameter values pass/return value of unexpected value (neg. num for price) run time exceptions method generates error due to conflicting resource needs unexpected state interactions states of two/more objects interact to cause complex failures o methods, classes, objects usability testing o determines whether a method, class, subsystem, system meets user requirements o often required b/c they involve functional/non-functional requirements o evaluates functional requirements use case by use case completed in each iteration test ease of learning + ease of use test accuracy feedback system, performance, stress testing o system test- integration test of entire system/independent subsystem performed at end of each iteration performed more frequently often tested + improved o performance test integration + usability test that determines whether a system /subsystem can meet time-based performance criteria response time throughput user acceptance testing o test performed to determine whether system fulfills user requirements o performed near end of project o formal activity o details of acceptance tests included in request for proposal (RFP) + procurement contract converting + initializing data o operational data requires fully populated database to support ongoing processing o data needed at system startup can be obtained from:

28 files, databases of system being replaced manual records files/databases from other systems in organization user feedback during normal system operation Training users o For end users + system operators o Emphasize hands-on use for specific business processes or functions (order entry, inventory control, accounting) Hands on training, practice excercises, questions + answers, tutorials o System operator training can be much less formal when operators aren t end users Development order o Input, process, output implements input modules, process modules, output modules o Top-down development development order that implements top-lvl modules first o Bottom- up development development order implements low-lvl detailed modules first Source Code control o Automated control for tracking source code files + controlling changes to those files o Read-only mode & read/write mode o Only one programmer at a time Planning & Managing (Implementation, testing and deployment) o Packaging, installing, deploying Issues Incurring costs of both systems in parallel Detecting + correcting errors Disrupting company & operations Training personnel & customers w/ new procedures Different approaches Direct deployment installs new system, quickly makes it operational, immediately turns off any overlapping systems o High risk, lower cost Parallel operates old & new systems for extended time period o Low risk, high cost Phased installs new system, makes operational in series of steps o Submitting error reports & change requests Standard reporting methods Review of requests by manager/committee Extensive planning for design/implementation o Impleneting change Identify what parts need change Secure resources/personnel Schedule design/implementation activities Develop test criteria/test plan o Change & version control tools & processes handle the complexity associated w/ testing & supporting a system through multiple versions

29 Alpha- incomplete but ready for some rigorous integration/testing Beta stable version to test by end uses over extended period of time Production version, release version/production release system version that is formally distributed to users or made operational for long-term use Maintenance release- a system update that provides bug fixes and small changes to existing features Chapter 13: Making the System Operational testing the process of examining a component subsystem, or sytem to determine its operational characteristics and whether it contains any defects test case aformal descript of a starting state, one or more events to which software must respond, and expected response or ending state o defined based on well understood functional and non-functional requirements o must test all normal and exception situations test data- set of starting states and events used to test a module, group of modules, entire system o data will be used for test case unit testing tests of an individual method, class, component before it is integrated w/ other software driver a method or class developed for unit testing that simulates behaviour of method that sends message to method being testsed stub a method or class developed for unit testing that simulates the behaviour of a method invoked that hasn t yet been written integration testing integration test tests of the behaviour of a group of methods, classes, components o interface incompatibility one method passes parameter of wrong data type to another method o parameter values method is passed/returns a value that was unexpected, such as neg. num for price o run-time exceptions a method generates an error, such as out of memory or file already in use due to conflicting resource needs o unexpected state interactions the states of two or more objects interact to cause complex failures integration testing of object-oriented software is very complex b/c an object-oriented program consists of set of interacting objects o Methods can be (and usually are) called by many other methods, and the calling methods may be distributed across many classes. o Classes may inherit methods and state variables from other classes. o The specific method to be called is dynamically determined at run time based on the number and type of message parameters.

30 o Objects can retain internal variable values (i.e., the object state) between calls. The response to two identical calls may be different due to state changes that result from the first call or occur between calls. usability testing Usability test test to determine whether a method, class, subsystem, system meets user requirements Many usability tests are required b c they involve functional + non-functional requirements Most common type evaluates functional requirements, use case by use case o Can be completed in each iteration as use cases are implemented o Can test ease of learning and ease of use o Can test whether results match actual requirements o Key type of feedback from users throughout project Testing System test an integration test of an entire system or independent subsystem o Can be performed at the end of each iteration o Can be performed more frequently o Build and smoke test a system test that is performed daily or several times a week The system is completely compiled and linked (built), and a battery of tests is executed to see whether anything malfunctions in an obvious way ( smokes ) Automated testing tools are used. Catches any problems that may have come up since the last system test System, performance, and stress testing Performance test or stress test an integration and usability test that determines whether a system or subsystem can meet time-based performance criteria o Response time the desired or maximum allowable time limit for software response to a query or update o Throughput the desired or minimum number of queries and transactions that must be processed per minute or hour User acceptance testing User acceptance test a system test performed to determine whether the system fulfills user requirements May be performed near the end of the project (or at end of later project iterations) A very formal activity in most development projects. Payments tied to passing tests Details of acceptance tests are sometimes included in the request for proposal (RFP) and procurement contract Converting and Initializing Data An operational system requires a fully populated database to support ongoing processing Data needed at system startup can be obtained from these sources:

31 o o o o Files or databases of a system being replaced Manual records Files or databases from other systems in the organization User feedback during normal system operation Training Users Training is needed for end users and system operators Training for end users must emphasize hands-on use for specific business processes or functions, such as order entry, inventory control, or accounting Widely varying skill and experience levels call for at least some hands-on training, including practice exercises, questions and answers, and one-on-one tutorials System operator training can be much less formal when the operators aren t end users Experienced computer operators and administrators can learn most or all they need to know by self-study Planning and Managing Implementation, Testing, and Deployment Development Order o Input, process, output (IPO) a development order that implements input modules first, process modules next, and output modules last o Top-down development a development order that implements top-level modules first Use stubs for testing o Bottom-up development a development order that implements low-level detailed modules first Use drivers for testing Source code control o An automated tool for tracking source code files and controlling changes to those files A programmer checks out a file in read-only mode when he or she wants to examine the code without making changes (e.g., to examine a module s interfaces to other modules) When a programmer needs to make changes to a file, he or she checks out the file in read/write mode The SCCS allows only one programmer at a time to check out a file in read/write mode. Packaging, installing, and deploying components o Issues to consider when planning Incurring costs of operating both systems in parallel Detecting and correcting errors in the new system Potentially disrupting the company and its IS operations Training personnel and familiarizing customers with new procedures o Different approaches Direct deployment Parallel deployment

32 Phased deployment Direct Deployment a deployment method that installs a new system, quickly makes it operational, and immediately turns off any overlapping systems o Higher risk, lower cost Parallel deployment a deployment method that operates the old and the new systems for an extended time period o Lower risk, higher cost Phased deployment - a deployment method that installs a new system and makes it operational in a series of steps or phases

33 Submitting Error Reports and Change Requests o Standard reporting methods o Review of requests by a project manager or change control committee o For operational systems, extensive planning for design and implementation Implementing a Change o Identify what parts of the system must be changed o Secure resources (such as personnel) to implement the change o Schedule design and implementation activities o Develop test criteria and a testing plan for the changed system Change and Version Control tools and processes handle the complexity associated with testing and supporting a system through multiple versions o Alpha version a test version that is incomplete but ready for some level of rigorous integration or usability testing o Beta version a test version that is stable enough to be tested by end users over an extended period of time o Production version, release version, or production release a system version that is formally distributed to users or made operational for long-term use o Maintenance release a system update that provides bug fixes and small changes to existing features

Chapter 10 Object-Oriented Design Principles

Chapter 10 Object-Oriented Design Principles Chapter 10 Object-Oriented Design Principles Dr. Supakit Nootyaskool Faculty of Information Technology King Mongkut s Institute of Technology Ladkrabang Outline Object-oriented design: bridging from analysis

More information

Information Technology Audit & Cyber Security

Information Technology Audit & Cyber Security Information Technology Audit & Cyber Security Structural Modeling Systems & Infrastructure Lifecycle Management OBJECTIVES demonstrate the differences between object diagrams and class diagrams, explain

More information

The Unified Modeling Language. Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL

The Unified Modeling Language. Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL The Unified Modeling Language Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL UML: requirement VS. Design models Identify 2 All the classes or things Elementary business process Necessary step to carry out

More information

Topic : Object Oriented Design Principles

Topic : Object Oriented Design Principles Topic : Object Oriented Design Principles Software Engineering Faculty of Computing Universiti Teknologi Malaysia Objectives Describe the differences between requirements activities and design activities

More information

Objectives. Explain the purpose and objectives of objectoriented. Develop design class diagrams

Objectives. Explain the purpose and objectives of objectoriented. Develop design class diagrams Objectives Explain the purpose and objectives of objectoriented design Develop design class diagrams Develop interaction diagrams based on the principles of object responsibility and use case controllers

More information

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization OBJECT ORIENTED DESIGN with the Unified Process Use Case Realization Objectives Explain the purpose and objectives of objectoriented design Develop design class diagrams Develop detailed sequence diagrams

More information

Systems Analysis and Design in a Changing World, Fourth Edition

Systems Analysis and Design in a Changing World, Fourth Edition Systems Analysis and Design in a Changing World, Fourth Edition Systems Analysis and Design in a Changing World, 4th Edition Learning Objectives Explain the purpose and various phases of the systems development

More information

Chapter : Analysis Modeling

Chapter : Analysis Modeling Chapter : Analysis Modeling Requirements Analysis Requirements analysis Specifies software s operational characteristics Indicates software's interface with other system elements Establishes constraints

More information

Requirements and Design Overview

Requirements and Design Overview Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions

More information

Software Service Engineering

Software Service Engineering Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language

More information

Object-Oriented Systems Analysis and Design Using UML

Object-Oriented Systems Analysis and Design Using UML 10 Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design, 8e Kendall & Kendall Copyright 2011 Pearson Education, Inc. Publishing as Prentice Hall Learning Objectives Understand

More information

UML Fundamental. OutLine. NetFusion Tech. Co., Ltd. Jack Lee. Use-case diagram Class diagram Sequence diagram

UML Fundamental. OutLine. NetFusion Tech. Co., Ltd. Jack Lee. Use-case diagram Class diagram Sequence diagram UML Fundamental NetFusion Tech. Co., Ltd. Jack Lee 2008/4/7 1 Use-case diagram Class diagram Sequence diagram OutLine Communication diagram State machine Activity diagram 2 1 What is UML? Unified Modeling

More information

Chapter 1: Principles of Programming and Software Engineering

Chapter 1: Principles of Programming and Software Engineering Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without

More information

Introduction - SENG 330. Object-Oriented Analysis and Design

Introduction - SENG 330. Object-Oriented Analysis and Design Introduction - SENG 330 Object-Oriented Analysis and Design SENG 330 Fall 2006 Instructor: Alex Thomo Email: thomo@cs.uvic.ca Office hours: Office Hours: TWF 12:30-1:30 p.m. Location: ECS 556 Objective:

More information

Software Architecture

Software Architecture Software Architecture Does software architecture global design?, architect designer? Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment

More information

SE 2730 Final Review

SE 2730 Final Review SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more

More information

Chapter 2: The Object-Oriented Design Process

Chapter 2: The Object-Oriented Design Process Chapter 2: The Object-Oriented Design Process In this chapter, we will learn the development of software based on object-oriented design methodology. Chapter Topics From Problem to Code The Object and

More information

*ANSWERS * **********************************

*ANSWERS * ********************************** CS/183/17/SS07 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2007 Answer ALL questions in Section A and TWO

More information

Object-Oriented Design and Modeling Using the UML

Object-Oriented Design and Modeling Using the UML Design Classes Object-Oriented Design and Modeling Using the UML Based on Chapter 18 of Whitten, Bentley, and Dittman: Systems Analysis and Design for the Global Enterprise (7th Ed). McGraw Hill. 2007

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration

More information

History of object-oriented approaches

History of object-oriented approaches Prof. Dr. Nizamettin AYDIN naydin@yildiz.edu.tr http://www.yildiz.edu.tr/~naydin Object-Oriented Oriented Systems Analysis and Design with the UML Objectives: Understand the basic characteristics of object-oriented

More information

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization OBJECT ORIENTED DESIGN with the Unified Process Use Case Realization 2016 Software Engineering 2 (Zoom-Into Design) Requirement Requirement Specification (Functional & Non- Functional) analysis Requirement

More information

Meltem Özturan

Meltem Özturan Meltem Özturan www.mis.boun.edu.tr/ozturan/samd 1 2 Modeling System Requirements Object Oriented Approach to Requirements OOA considers an IS as a set of objects that work together to carry out the function.

More information

SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A

SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A 1. What is an object? An object is a combination of data and logic; the representation of some realworld

More information

1. Introduction to Object Oriented Software Development

1. Introduction to Object Oriented Software Development 1. Introduction to Object Oriented Software Development a) Object: A set of data together with some operations that can be performed on that data. Eg. Bank Account. Data can be account number, name of

More information

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS6403 SOFTWARE ENGINEERING II year/ IV sem CSE (Regulation 2013) UNIT 1- SOFTWARE PROCESS AND PROJECT

More information

06. Analysis Modeling

06. Analysis Modeling 06. Analysis Modeling Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 Overview of Analysis Modeling 1 Requirement Analysis 2 Analysis Modeling Approaches

More information

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK TWO MARKS UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering? Software engineering

More information

This tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.

This tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping. i About the Tutorial SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. This tutorial will give

More information

Object Oriented Analysis and Design - Part2(Design)

Object Oriented Analysis and Design - Part2(Design) Object Oriented Analysis and Design - Part2(Design) Exam A QUESTION 1 Which statement is true about elements within the subsystem and public visibility? A. Only the subset of elements that define the subsystems

More information

Chapter 10. Object-Oriented Analysis and Modeling Using the UML. McGraw-Hill/Irwin

Chapter 10. Object-Oriented Analysis and Modeling Using the UML. McGraw-Hill/Irwin Chapter 10 Object-Oriented Analysis and Modeling Using the UML McGraw-Hill/Irwin Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Objectives 10-2 Define object modeling and explain

More information

SOFTWARE ENGINEERING. Lecture 6. By: Latifa ALrashed. Networks and Communication Department

SOFTWARE ENGINEERING. Lecture 6. By: Latifa ALrashed. Networks and Communication Department 1 SOFTWARE ENGINEERING Networks and Communication Department Lecture 6 By: Latifa ALrashed Outline q q q q q q q q Define the concept of the software life cycle in software engineering. Identify the system

More information

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : ,

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : , Course Code : MCS-032 Course Title : Object Oriented Analysis and Design Assignment Number : MCA (3)/032/Assign/2014-15 Assignment Marks : 100 Weightage : 25% Last Dates for Submission : 15th October,

More information

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh SOFTWARE DESIGN COSC 4353 / 6353 Dr. Raj Singh UML - History 2 The Unified Modeling Language (UML) is a general purpose modeling language designed to provide a standard way to visualize the design of a

More information

A - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models

A - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models CS 494 Object-Oriented Analysis & Design UML Class Models Overview How class models are used? Perspectives Classes: attributes and operations Associations Multiplicity Generalization and Inheritance Aggregation

More information

OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis

OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance

More information

Introducing the UML Eng. Mohammed T. Abo Alroos

Introducing the UML Eng. Mohammed T. Abo Alroos Introducing the UML Eng. Mohammed T. Abo Alroos Islamic University of Gaza Introduction to the UML: The UML stands for Unified Modeling Language. It was released in 1997 as a method to diagram software

More information

OO Project Management

OO Project Management OO Project Management Twin Cities Java User s Group November 17, 1999 Mary Poppendieck Poppendieck.LLC Object Oriented Development Objects Simulate the Real World Example: Process Control On/Off Switch

More information

Unified Modeling Language (UML)

Unified Modeling Language (UML) Appendix H Unified Modeling Language (UML) Preview The Unified Modeling Language (UML) is an object-oriented modeling language sponsored by the Object Management Group (OMG) and published as a standard

More information

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis. SOFTWARE ENGINEERING UML FUNDAMENTALS Saulius Ragaišis saulius.ragaisis@mif.vu.lt Information source Slides are prepared on the basis of Bernd Oestereich, Developing Software with UML: Object- Oriented

More information

1. i. What are the 3 major components of a information system and show their relationship input output

1. i. What are the 3 major components of a information system and show their relationship input output Higher National Diploma in Information Technology First Year, Second semesterexamination-2011 IT2005: System Analysis and Design Answer Script No. of pages: 11 1. i. What are the 3 major components of

More information

Introduction to Software Engineering

Introduction to Software Engineering Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,

More information

UNIT I. 3. Write a short notes on process view of 4+1 architecture. 4. Why is object-oriented approach superior to procedural approach?

UNIT I. 3. Write a short notes on process view of 4+1 architecture. 4. Why is object-oriented approach superior to procedural approach? Department: Information Technology Questions Bank Class: B.E. (I.T) Prof. Bhujbal Dnyaneshwar K. Subject: Object Oriented Modeling & Design dnyanesh.bhujbal11@gmail.com ------------------------------------------------------------------------------------------------------------

More information

Hippo Software BPMN and UML Training

Hippo Software BPMN and UML Training Hippo Software BPMN and UML Training Icon Key: www.hippo-software.co.uk Teaches theory concepts and notation Teaches practical use of Enterprise Architect Covers BPMN, UML, SysML, ArchiMate Includes paper

More information

Enterprise Architect Training Courses

Enterprise Architect Training Courses On-site training from as little as 135 per delegate per day! Enterprise Architect Training Courses Tassc trainers are expert practitioners in Enterprise Architect with over 10 years experience in object

More information

UML Views of a System

UML Views of a System UML Views of a System The architecture of a system is the fundamental organization of the system as a whole. The five UML Views: Use Case View: focuses on scenarios Design View: focuses on the vocabulary

More information

Systems Analysis & Design

Systems Analysis & Design Systems Analysis & Design Dr. Ahmed Lawgali Ahmed.lawgali@uob.edu.ly Slide 1 Systems Analysis & Design Course Textbook: Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition

More information

Lab Manual. Object Oriented Analysis And Design. TE(Computer) VI semester

Lab Manual. Object Oriented Analysis And Design. TE(Computer) VI semester Lab Manual Object Oriented Analysis And Design TE(Computer) VI semester Index Sr. No. Title of Programming Assignment Page No. 1 2 3 4 5 6 7 8 9 10 Study of Use Case Diagram Study of Activity Diagram Study

More information

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A (UML Notations has to be used wherever necessary)

More information

Basic Structural Modeling. Copyright Joey Paquet,

Basic Structural Modeling. Copyright Joey Paquet, Basic Structural Modeling Copyright Joey Paquet, 2000 1 Part I Classes Copyright Joey Paquet, 2000 2 Classes Description of a set of objects sharing the same attributes, operations and semantics Abstraction

More information

Introduction to UML What is UML? Motivations for UML Types of UML diagrams UML syntax Descriptions of the various diagram types Rational Rose (IBM.. M

Introduction to UML What is UML? Motivations for UML Types of UML diagrams UML syntax Descriptions of the various diagram types Rational Rose (IBM.. M Introduction to UML Part I 1 What is UML? Unified Modeling Language, a standard language for designing and documenting a system in an object- oriented manner. It s a language by which technical architects

More information

Chapter 1: Programming Principles

Chapter 1: Programming Principles Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key

More information

Examples. Object Orientated Analysis and Design. Benjamin Kenwright

Examples. Object Orientated Analysis and Design. Benjamin Kenwright Examples Object Orientated Analysis and Design Benjamin Kenwright Outline Revision Questions Group Project Review Deliverables Example System Problem Case Studey Group Project Case-Study Example Vision

More information

Chapter 5: Structural Modeling

Chapter 5: Structural Modeling Chapter 5: Structural Modeling Objectives Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. Understand the processes used to create CRC cards, class

More information

COSC 3351 Software Design. An Introduction to UML (I)

COSC 3351 Software Design. An Introduction to UML (I) COSC 3351 Software Design An Introduction to UML (I) This lecture contains material from: http://wps.prenhall.com/esm_pfleeger_softengtp_2 http://sunset.usc.edu/classes/cs577a_2000/lectures/05/ec-05.ppt

More information

Responsive Redesign dispatch.com 10tv.com thisweeknews.com

Responsive Redesign dispatch.com 10tv.com thisweeknews.com Responsive Redesign 2014 dispatch.com 10tv.com thisweeknews.com Project Goals Establish a one web content strategy Share templates and interaction design patterns across brands Provide enough flexibility

More information

SEEM4570 System Design and Implementation Lecture 11 UML

SEEM4570 System Design and Implementation Lecture 11 UML SEEM4570 System Design and Implementation Lecture 11 UML Introduction In the previous lecture, we talked about software development life cycle in a conceptual level E.g. we need to write documents, diagrams,

More information

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 9 OO modeling Design Patterns Structural Patterns Behavioural Patterns

More information

Final Exam CISC 475/675 Fall 2004

Final Exam CISC 475/675 Fall 2004 True or False [2 pts each]: Final Exam CISC 475/675 Fall 2004 1. (True/False) All software development processes contain at least separate planning, testing, and documentation phases. 2. (True/False) The

More information

Unit Wise Questions. Unit-1 Concepts

Unit Wise Questions. Unit-1 Concepts Unit Wise Questions Unit-1 Concepts Q1. What is UML? Ans. Unified Modelling Language. It is a Industry standard graphical language for modelling and hence visualizing a blue print of all the aspects of

More information

CASE TOOLS LAB VIVA QUESTION

CASE TOOLS LAB VIVA QUESTION 1. Define Object Oriented Analysis? VIVA QUESTION Object Oriented Analysis (OOA) is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary

More information

Appendix A - Glossary(of OO software term s)

Appendix A - Glossary(of OO software term s) Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component

More information

UNIT-I Introduction of Object Oriented Modeling

UNIT-I Introduction of Object Oriented Modeling UNIT-I Introduction of Object Oriented Modeling - Prasad Mahale Object Oriented Modeling and Reference Books: Design 1. Grady Booch, James Rumbaugh, Ivar Jacobson Unified Modeling Language User Guide,

More information

5 Object Oriented Analysis

5 Object Oriented Analysis 5 Object Oriented Analysis 5.1 What is OOA? 5.2 Analysis Techniques 5.3 Booch's Criteria for Quality Classes 5.4 Project Management and Iterative OOAD 1 5.1 What is OOA? How to get understanding of what

More information

Lesson 11. W.C.Udwela Department of Mathematics & Computer Science

Lesson 11. W.C.Udwela Department of Mathematics & Computer Science Lesson 11 INTRODUCING UML W.C.Udwela Department of Mathematics & Computer Science Why we model? Central part of all the activities We build model to Communicate Visualize and control Better understand

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

Software Engineering with Objects and Components Open Issues and Course Summary

Software Engineering with Objects and Components Open Issues and Course Summary Software Engineering with Objects and Components Open Issues and Course Summary Massimo Felici Software Engineering with Objects and Components Software development process Lifecycle models and main stages

More information

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements Journal of Software Engineering and Applications, 2016, 9, 112-127 Published Online April 2016 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2016.94010 The Analysis and Proposed

More information

INTERNAL ASSESSMENT TEST III Answer Schema

INTERNAL ASSESSMENT TEST III Answer Schema INTERNAL ASSESSMENT TEST III Answer Schema Subject& Code: Object-Oriented Modeling and Design (15CS551) Sem: V ISE (A & B) Q. No. Questions Marks 1. a. Ans Explain the steps or iterations involved in object

More information

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (Autonomous) (ISO/IEC Certified)

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (Autonomous) (ISO/IEC Certified) Important Instructions to examiners: 1) The answers should be examined by key words and not as word-to-word as given in the model answer scheme. 2) The model answer and the answer written by candidate

More information

Lecture 8 Requirements Engineering

Lecture 8 Requirements Engineering Lecture 8 Requirements Engineering Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 18, 2008 Lecture Overview

More information

User-Centered Development

User-Centered Development Software Lifecycle CS470 User-Centered Development User-centered development refers to a design process for creating a system that meets the needs of the user Users should be included in the design process

More information

Identify the guidelines for system development. Discuss the purpose of the activities performed in the analysis phase

Identify the guidelines for system development. Discuss the purpose of the activities performed in the analysis phase Discovering Computers 2010 Living in a Digital World Objectives Overview Define system development and list the system development phases Identify the guidelines for system development Discuss the importance

More information

Object Design II: Design Patterns

Object Design II: Design Patterns Object-Oriented Software Engineering Using UML, Patterns, and Java Object Design II: Design Patterns Bernd Bruegge Applied Software Engineering Technische Universitaet Muenchen A Game: Get-15 The game

More information

Outline of UML and Unified Process. Object Oriented Analysis/Design/Programming UML1.5. Koichiro Ochimizu, JAIST. UML&UP outline 1.

Outline of UML and Unified Process. Object Oriented Analysis/Design/Programming UML1.5. Koichiro Ochimizu, JAIST. UML&UP outline 1. Outline of UML and Unified Process Koichiro OCHIMIZU School of Information Science JAIST Schedule Feb. 27th 13:00 Scope and Goal 14:30 Basic Concepts on Representing the World (object, class, association,

More information

Analysis and Design with UML

Analysis and Design with UML Analysis and Design with UML Page 1 Agenda Benefits of Visual Modeling History of the UML Visual Modeling with UML The Rational Iterative Development Process Page 2 What is Visual Modeling? Item Order

More information

CS485/540 Software Engineering Requirements Modeling (Ch. 6)

CS485/540 Software Engineering Requirements Modeling (Ch. 6) CS485/540 Software Engineering Requirements Modeling (Ch. 6) Cengiz Günay Dept. Math & CS, Emory University Fall 2013 Some slides courtesy of Joan Smith and Roger Pressman Günay (Emory) Requirements Modeling

More information

ArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology

ArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology ArchiMate Core Structural Concepts Behavioral Concepts Informational Concepts interaction Technology Application Layer Concept Description Notation Concept Description Notation Actor An organizational

More information

Object-Oriented Software Engineering Practical Software Development using UML and Java

Object-Oriented Software Engineering Practical Software Development using UML and Java Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical

More information

TASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE

TASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE SUMMARY AND REFERENCE ACTG 313 TASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE PREPARATION PHASE 1. Identification of the Need for a new Information System 2. Initial Feasibility Study (always flawed because

More information

Change Management Process on Database Level within RUP Framework

Change Management Process on Database Level within RUP Framework Change Management Process on Database Level within RUP Framework ZELJKA CAR*, PETRA SVOBODA**, CORNELIA KRUSLIN** *Department of Telecommunications Faculty of Electrical Engineering Computing, University

More information

PPSC Competitive Exam for the Post of System Analyst

PPSC Competitive Exam for the Post of System Analyst PPSC Competitive Exam for the Post of System Analyst Question Paper Along with Answer Key Date: 21 st June, 2014 Time: 09: 00 AM to 11:00 AM Total Number of Questions: 100 Q 1. Which of the following is

More information

Object-Oriented Design

Object-Oriented Design Software and Programming I Object-Oriented Design Roman Kontchakov / Carsten Fuhs Birkbeck, University of London Outline Discovering classes and methods Relationships between classes An object-oriented

More information

System development, design & implementation

System development, design & implementation System development, design & implementation Design of software The following are the principle for any software design : Modularity and partitioning : Top down methods are used through out the analysis

More information

OBJECT-ORIENTED MODELING AND DESIGN. Process Overview

OBJECT-ORIENTED MODELING AND DESIGN. Process Overview OBJECT-ORIENTED MODELING AND DESIGN Process Overview CONTENTS: 1. Development Stages. 2. Development Life Cycle. 3. Summary. A software Development process provides a basis for the organized production

More information

SE 1: Software Requirements Specification and Analysis

SE 1: Software Requirements Specification and Analysis SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 U Waterloo SE1 (Winter 2006)

More information

CaseComplete Roadmap

CaseComplete Roadmap CaseComplete Roadmap Copyright 2004-2014 Serlio Software Development Corporation Contents Get started... 1 Create a project... 1 Set the vision and scope... 1 Brainstorm for primary actors and their goals...

More information

Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1

Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1 Failure Rate Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1 SOFTWARE (What is Software? Explain characteristics of Software. OR How the software product is differing than

More information

3Lesson 3: Web Project Management Fundamentals Objectives

3Lesson 3: Web Project Management Fundamentals Objectives 3Lesson 3: Web Project Management Fundamentals Objectives By the end of this lesson, you will be able to: 1.1.11: Determine site project implementation factors (includes stakeholder input, time frame,

More information

Introduction to Software Engineering

Introduction to Software Engineering Chapter 1 Introduction to Software Engineering Content 1. Introduction 2. Components 3. Layered Technologies 4. Generic View of Software Engineering 4. Generic View of Software Engineering 5. Study of

More information

Architectural Blueprint

Architectural Blueprint IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint

More information

SE 1: Software Requirements Specification and Analysis

SE 1: Software Requirements Specification and Analysis SE 1: Software Requirements Specification and Analysis Lecture 9: UML Class (Concept), Object, Communication Diagrams Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445

More information

Week 9 Implementation

Week 9 Implementation Week 9 Implementation Dr. Eliane l. Bodanese What is more important From a software engineering perspective: Good Gui? does what customer wants maintainable, extensible, reusable Commented Code? how is

More information

Project #1 rev 2 Computer Science 2334 Fall 2013 This project is individual work. Each student must complete this assignment independently.

Project #1 rev 2 Computer Science 2334 Fall 2013 This project is individual work. Each student must complete this assignment independently. Project #1 rev 2 Computer Science 2334 Fall 2013 This project is individual work. Each student must complete this assignment independently. User Request: Create a simple magazine data system. Milestones:

More information

Lecture Chapter 2 Software Development

Lecture Chapter 2 Software Development Lecture Chapter 2 Software Development Large Software Projects Software Design o Team of programmers o Cost effective development Organization Communication Problem Solving Analysis of the problem Multiple

More information

1: Introduction to Object (1)

1: Introduction to Object (1) 1: Introduction to Object (1) 김동원 2003.01.20 Overview (1) The progress of abstraction Smalltalk Class & Object Interface The hidden implementation Reusing the implementation Inheritance: Reusing the interface

More information

Architecture and the UML

Architecture and the UML Architecture and the UML Models, Views, and A model is a complete description of a system from a particular perspective Use Case Use Case Sequence Use Case Use Case Use Case State State Class State State

More information

QM Chapter 1 Database Fundamentals Version 10 th Ed. Prepared by Dr Kamel Rouibah / Dept QM & IS

QM Chapter 1 Database Fundamentals Version 10 th Ed. Prepared by Dr Kamel Rouibah / Dept QM & IS QM 433 - Chapter 1 Database Fundamentals Version 10 th Ed Prepared by Dr Kamel Rouibah / Dept QM & IS www.cba.edu.kw/krouibah Dr K. Rouibah / dept QM & IS Chapter 1 (433) Database fundamentals 1 Objectives

More information

Darshan Institute of Engineering & Technology for Diploma Studies

Darshan Institute of Engineering & Technology for Diploma Studies REQUIREMENTS GATHERING AND ANALYSIS The analyst starts requirement gathering activity by collecting all information that could be useful to develop system. In practice it is very difficult to gather all

More information

LABORATORY 1 REVISION

LABORATORY 1 REVISION UTCN Computer Science Department Software Design 2012/2013 LABORATORY 1 REVISION ================================================================== I. UML Revision This section focuses on reviewing the

More information