ITM 305 Midterm Exam Lecture Notes 1-5 PDF

lOMoARcPSD|40733896 ITM 305 Midterm Exam - Lecture notes 1-5 System Analysis and Design (Toronto Metropolitan University) Scan to open on Studocu Studocu is not sponsored or endorsed by any college or university Downloaded by jeff thrid (a...

lOMoARcPSD|40733896 ITM 305 Midterm Exam - Lecture notes 1-5 System Analysis and Design (Toronto Metropolitan University) Scan to open on Studocu Studocu is not sponsored or endorsed by any college or university Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 ITM 305 Midterm Exam Week 1 Systems Analyst: - Implements, maintains, and supports IT and info systems to meet the business need of organizations and scale as organizations grow. - Analyzes/creates tests and develops specifications and requirements for developers and programmers to follow. - Usually not involved directly in software or hardware development. - Have a bachelor’s degree in computer science, info tech, engineering or info systems. - Have excellent analytical skills and are creative problem solvers. - Average salary is 119K Software Development: Computer application (app) – a computer software program that executes on a computing device to carry out a specific set of functions Modest scope Information system – a set of interrelated components that collects, processes, stores, and provides as output the information needed to complete business tasks Broader in scope than “app” Includes database and related manual processes Systems analysis – those activities that enable a person to understand and specify what an information system should accomplish Systems design – those activities that enable a person to define and describe in detail the system that solves the need 7 Steps of Software Development 1. Understand the need (business need/nature of the problem) 2. Capture the vision 3. Define a solution 4. Communicate the vision and solution 5. Build the solution 6. Confirm that the solution meets the need 7. Launch the solution system Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 System Development Life Cycle (SDLC): The process consisting of all activities required to build, launch, and maintain an information system. Six core processes are: 1. Identify the problem or need and obtain approval 2. Plan and monitor the project 3. Discover and understand the details of the problem or need 4. Design the system components that solve the problem 5. Build, test, and integrate system components 6. Complete system tests and then deploy the solution Project – a planned undertaking that has a beginning and end and that produces some definite result Used to develop an information system Requires knowledge of systems analysis and systems design tools and techniques System development process – the actual approach used to develop a particular information system (aka: methodology) Most processes/methodologies now use Agile and Iterative development Iterative Development: Agile development – an information system development process that emphasizes flexibility to anticipate new requirements during development. Agile is a form of iterative development. Fast on feet; responsive to change Iterative development -- an approach to system development in which the system is “grown” piece by piece through multiple iterations Complete small part of system (mini-project), then repeat processes to refine and add more, then repeat to refine and add more, until done Iterative and Agile Systems Development Lifecycle (SDLC) Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Core Process 1 – Pre-project Identify the problem and document the objective of the system (core process 1) Preliminary investigation System Vision Document Obtain approval to commence the project (core process 1) Meet with key stakeholders, including executive management Decision reached, approve plan and budget Core Process 2 – Plan the Project Determine the major components (functional areas) that are needed Define the iterations and assign each function to an iteration Determine team members and responsibilities Core Process 3 – Discover and Understand Details  Do preliminary fact-finding to understand requirements  Develop a preliminary list of use cases and a use case diagram  Develop a preliminary list of classes and a class diagram Core Process 4 – Design System Components  Design the database (schema)  Design the system’s high-level structure  Browser, Windows, or Smart phone  Architectural configuration (components)  Design class diagram  Subsystem architectural design Core Process 5 – Build, Test, and Integrate System Components  Continue programming (build)  Build use case by use case  Perform unit and integration tests Core Process 6 – Complete System Testing and Deploy the System  Perform system functional testing  Perform user acceptance testing  Possibly deploy part of system Two General SDLC Approaches:  Predictive Approach to the SDLC  Waterfall model  Assumes the project can be planned in advance and that the information system can be developed according to the plan Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  Requirements are well understood and/or low technical risk  Adaptive Approach to the SDLC  Iterative model (as presented in this course)  Assumes the project must be more flexible and adapt to changing needs as the project progresses  Requirements and needs are uncertain and/or high technical risk Traditional Predictive SDLC:  Earlier approach based on engineering  Typically have sequential Phases  Phases are related groups of development activities, such as planning, analysis, design, implementation, and deployment  Waterfall model  SDLC that assumes phases can be completed sequentially with no overlap or iteration  Once one phase is completed, you fall over the waterfall to the next phase, no going back Newer Adaptive SDLC Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  Emerged in response to increasingly complex requirements and uncertain technological environments  Always includes iterations where some of design and implementation is done from the beginning  Most developers now claim it is the only way to develop information systems  Many IS managers are still sceptical due to apparent lack of overall plan but that is rapidly changing Methodologies  A way to do things.  UML is the methodology we use.  Provides guidelines for every facet of system development: What to do when, why and how  Specifies an SDLC with activities and tasks  Specifies project planning and project management models and reporting  Specifies analysis and design models to create  Specifies implementation and testing techniques  Specifies deployment and support techniques  Other term used is System Development Process  A Methodology includes a collection of techniques that are used to complete activities and tasks, including modelling, for every aspect of the project Model  An abstraction of an important aspect of the real world.  Makes it possible to understand a complex concept by focusing only on a relevant part  Each model shows a different aspect of the concept  Crucial for communicating project information  In IS models are of system components that will be developed  Other models are used to manage the development process Tools  Software applications that assists developers in creating models or other components required for a project  Integrated Development Environment (IDE) Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  set of tools that work together to provide a comprehensive development environment  Visual Modelling Tools  Tools to create graphical models Week 2 System Analysis Activities  Gather Detailed Information  Interviews, questionnaires, documents, observing similar business processes, researching vendors, comments and suggestions  Define Requirements  Modeling functional requirements and defining non-functional requirements  Prioritize Requirements  Essential, important, vs. nice to have  Develop User-Interface Dialogs  Flow of interaction between user and system  Evaluate Requirements with Users  User involvement, feedback, adapt to changes Information Gathering Techniques  Interviewing users and other stakeholders  Distributing and collecting questionnaires  Reviewing inputs, outputs, and documentation  Observing and documenting business procedures  Researching vendor solutions  Collecting active user comments and suggestions Interviewing Users and Other Stakeholders  Prepare detailed questions  Meet with individuals or groups of users Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  Obtain and discuss answers to the questions  Document the answers  Follow up as needed in future meetings or interviews Themes for Information Gathering Questions Additional Techniques  Observe and Document Business Processes  Watch and learn  Document with Activity diagram (next section)  Research Vendor Solutions  See what others have done for similar situations  White papers, vendor literature, competitors  Collect Active User Comments and Suggestions  Feedback on models and tests  Users know it when they see it Requirements  System Requirements =  Functional requirements  Non-functional requirements  Functional Requirements– the activities the system must perform  Business uses, functions the users carry out  Use Cases  Non-Functional Requirements– other system characteristics  Constraints and performance goals FURPS+ Requirements Acronym  Functional requirements  Usability requirements  Reliability requirements  Performance requirements  Security requirements  + even more categories… Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Additional Requirements Categories  Design constraints –  Specific restrictions for hardware and software  Implementation requirements  Specific languages, tools, protocols, etc.  Interface requirements  Interface links to other systems  Physical requirements  Physical facilities and equipment constraints  Supportability requirements  Automatic updates and enhancement methods Stakeholders  Stakeholders– persons who have an interest in the successful implementation of the system  Internal Stakeholders– persons within the organization  External stakeholders – persons outside the organization  Operational stakeholders – persons who regularly interact with the system  Executive stakeholders– persons who don’t directly interact, but use the information or have financial interest Stakeholders of a comprehensive accounting system for public company: Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Models and Modeling  How do we define requirements? After collecting information, create models  Model– a representation of some aspect of the system being built  Types of Models  Textual model– something written down, described  Graphical models– diagram, schematic  Mathematical models– formulas, statistics, algorithms  Unified Modeling Language (UML)  Standard graphical modeling symbols/terminology used for information systems Reasons for Modeling  Learning from the modeling process  Reducing complexity by abstraction  Remembering all the details  Communicating with other development team members  Communicating with a variety of users and stakeholders  Documenting what was done for future maintenance/enhancement Use Cases  Use case— an activity that the system performs, usually in response to a request by a user  A Use Case describes the behaviour of a business system from the business user’s point of view. It should describe in plain business terms how the user interacts with the system (assuming it is an online Use Case) and what the system does in response. It does not determine how the system works internally, that is it does not define the implementation.  Use cases define functional requirements  Analysts decompose the system into a set of use cases (functional decomposition)  Two techniques for Identifying use cases Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  User goal technique  Event decomposition technique  Name each use case using Verb-Noun User Goal Technique: 1. Identify all potential users for the new system 2. Classify the potential users in terms of their functional role (e.g. shipping, marketing, sales) 3. Further classify potential users by organizational level (e.g. operational, management, executive) 4. For each type of user, interview them to find a list of specific goals they will have when using the new system (current goals and innovative functions to add value) 5. Create a list of preliminary use cases organized by type of user 6. Look for duplicates with similar use case names and resolve inconsistencies 7. Identify where different types of users need the same use cases 8. Review the completed list with each type of user and then with interested stakeholders Use Case Diagrams  Use case diagrams – a UML model used to graphically show use cases and their relationships to actors.  Recall UML, the standard for diagrams and terminology for developing info systems  Actor is the UML name for an end user. In this course, we only identify primary actors – the initiator of the use case  System boundary – the boundary between total application and the users who operate the application.  Automation boundary – the boundary between the computerized portion of the application and the users who operate the application. Use case symbols: Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Includes: Whenever we fill the shopping cart, we must search products. Main case includes sub case. We can’t do this… without doing this… Mandatory subprocess; it MUST happen. Extends: Optional subprocess. We can fill the shopping cart without removing a product. Only done under certain circumstances. - The «include» relationship allows us to include the steps from one Use Case into another. This is valuable when the included steps occur as a recognisable sequence in many different contexts. - The time to use the «include» relationship is after you have completed the first cut description of all your main Use Cases. - You can now look at the Use Cases and identify common sequences of user-system interaction. Do not attempt to do this earlier as it will be hard to justify the included Use Cases and they are likely to be more of a distraction than a help at this stage. Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 - Each included Use Case is an essential part of the complete description of the base Use Case. - The «extend» relationship allows us to modify the behaviour of the base Use Case. Suppose we want to sell products that are made to order and require a degree of customer specification. For these products we will need to record the customer’s additional requirements, such as size and colour. In this case we are adding something extra to the flow of the base Use Case. - A Use Case is too big. If a use Case description, with all its alternative flows is becoming unmanageable, use this as a strategy to break it up. Take a substantial alternative path, that is reasonably self-contained and make it an extending Use Case. - The base Use Case is something that for one reason or another we don’t want to change. It may be that the base Use Case is part of an existing system implementation and we want to create a Use Case description for the new functionality - Where we want to delay delivery of some flows within the Use Case. We normally use Use Cases to define the scope of our increments and occasionally this causes us a problem if we want to partially implement a function and withhold some features until a later increment. Week 3 Event Decomposition More Comprehensive and Complete Technique Identify the events that occur to which the system must respond. For each event, name a use case (verb-noun) that describes what the system does when the event occurs Event– something that occurs at a specific time and place, can be described, and should be remembered by the system Types of Events External Event an event that occurs outside the system, usually initiated by an external actor Temporal Event an event that occurs as a result of reaching a point in time State Event an event that occurs when something happens inside the system that triggers some process reorder point is reached for inventory item External Event Checklist External actor wants something resulting in a transaction Customer buys a product External actor wants some information Customer wants to know product details Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 External data changed and needs to be updated Customer has new address and phone Management wants some information Sales manager wants update on production plans Temporal Event Checklist Internal outputs needed at points in time Management reports (summary or exception) Operational reports (detailed transactions) Internal statements and documents (including payroll) External outputs needed at points of time Statements, status reports, bills, reminders Perfect Technology Assumption Don’t worry about functions built into system because of limits in technology and people. Wait until design. Also assume that no errors will occur. Event Decomposition Technique 1. Consider the external events in the system environment that require a response from the system 2. For each external event, identify and name the use case that the system requires 3. Consider the temporal events that require a response from the system 4. For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case 5. Consider the state events that the system might respond to, particularly if it is a real- time system in which devices or internal state changes trigger use cases. 6. For each state event, identify and name the use case that the system requires and then define the state change. 7. When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later. 8. Don’t consider “data or status error” conditions. Benefits of Decomposition Technique Events are broader than user goal: Capture temporal and state events Help decompose at the right level of analysis: an elementary business process (EBP) EBP is a fundamental business process performed by one person, in one place, in response to a business event Uses perfect technology assumption to make sure functions that support the users work are identified and not additional functions for error checking, security and system controls Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Generalization – Use Case Use a Generalization relation to show that a specialized use case is a particular way to achieve the goals expressed by another general use case. The open arrowhead should point at the more general use case. NOTE: This concept is presented for completeness. It is rarely if ever used. | V Generalization – Actors You can draw a Generalization link between Actors. The specialized actor, such as Club Customer in the example, inherits the use cases of the generalized actor, such as Customer. The arrowhead should point at the more general actor, such as Customer. When you create the link, point first at the more specialized actor. The specialized actor can have its own additional use cases that are not available to the other actors. | V Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Primary Use Case A Primary Use Case is a logical unit of functionality identified as a user requirement of the system. Each Primary Use Case corresponds to a logical unit of work, so that as a rule of thumb it is typically performed by one person, in one place, at one time leaves the business data in a consistent state generates some business value Secondary Use Case A Secondary Use Case is a refinement of the Use Case Model that are identified as included or extending Use Cases. Week 4 Use Case Template  Use case name  Scenario (if needed)  Triggering event  Brief description  Actors  Related use cases ( / )  Stakeholders  Preconditions  Postconditions  Flow of activities  Exception conditions Use Case Description Details  Use case name  Verb-noun  Scenario (if needed)  A use case can have more than one scenario (special case or more specific path)  Triggering event  Based on event decomposition technique  Brief description  Written previously when use case was identified Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  Actors  One or more users from use case diagrams  Related use cases ,  If one use case invokes another  Stakeholders  Anyone with an interest in the use case  Preconditions  What must be true before the use case begins  Post conditions  What must be true when the use case is completed  Use for planning test case expected results  Changes to the data  Flow of activities  The activities that go on between actor and the system  Exception condition  Where and what can go wrong Fully Developed Use Case Description (Use case: Create customer account) Workflow Sequence of processing steps that completely handles one business transaction or customer request Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Activity Diagram Describes user and system activities, the actor who does each activity, and the sequential flow of these activities  Useful for showing a graphical model of a workflow  A UML diagram  The main reason to use activity diagrams is to model the workflow behind the system being designed.  Activity Diagrams are also useful for:  analyzing a use case by describing what actions need to take place and when they should occur  describing a complicated sequential algorithm  Activity diagrams do not give detail about how objects behave or how objects collaborate. Activity  An activity is an ongoing execution of a step in a workflow (such as an operation or transaction)  Represented with a rounded rectangle.  Text in the activity box should represent an activity (verb phrase in present tense). Branch  A branch describes what activities will take place based on a set of conditions.  All the YES/NO flows from branches will merge together at some point to indicate the end of the conditional behavior started by that branch. UML Activity Diagram for Use Case (Create Customer Account) Note: This shows flow of activities only Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Activity Diagram for Ship Items Use Case Note: - Synchronization bar for loop - Decision diamond UML Activity Diagram for Use Case Fill Shopping Cart Note: Shows use case with relationship Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Week 5: Domain Classes Problem Domain contains - Data entities - Domain classes Class Diagrams  Class diagram is a static diagram and it is used to model static view of a system. The static view describes the vocabulary of the system.  Generally, UML diagrams are not directly mapped with any object-oriented programming languages but the class diagram is an exception.  Class diagram clearly shows the mapping with object-oriented languages like Java, C++ etc. So from practical experience class diagram is generally used for construction purpose.  So in a brief, class diagrams are used for:  Describing the static view of the system.  Showing the collaboration among the elements of the static view.  Describing the functionalities performed by the system.  Construction of software applications using object-oriented languages. Things in the Problem Domain Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  Problem domain—the specific area (or domain) of the users’ business need that is within the scope of the new system.  “Things” are those items users work with when accomplishing tasks that need to be remembered  Examples of “Things” are products, sales, shippers, customers, invoices, payments, etc.  These “Things” are modeled as domain classes or data entities  In this course, we will call them domain classes. In database class you call them data entities Two Techniques for Identifying them  Brainstorming Technique  Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type  Are there any tangible things? Are there any organizational units? Sites/locations? Are there incidents or events that need to be recorded?  Noun Technique  Identify all of the 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  A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents  Popular technique. Systematic.  Does end up with long lists and many nouns that are not things that need to be stored by the system  Difficulty identifying synonyms and things that are really attributes  Good place to start when there are no users available to help brainstorm Noun Technique 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, Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 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. Details about Domain Classes  Attribute— describes one piece of information about each instance of the class  Customer has first name, last name, phone number.  Natural keys are attributes that are in the business system already.  Class is a type of thing. Object is a specific instance of a class. Each instance has its own value for an attribute.  Identifier or key  One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer  Because this can be tricky in UML we will not do this  Compound attribute  Two or more attributes combined into one structure to simplify the model. (E.g., address rather than including number, street, city, state, zip separately). Sometimes an identifier or key is a compound attribute. Association on class diagram in UML  Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many  We are emphasizing UML in this text Relationship on ERD in database class  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  Read them separately each way  A customer places an order  An order is placed by a customer Minimum and Maximum Multiplicity  Associations have minimum and maximum constraints Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 o minimum is zero, the association is optional o If minimum is at least one, the association is mandatory Types of Associations  Binary Association o Associations between exactly two different classes  Course Section includes Students  Members join Club  Unary Association (recursive) o Associations between two instances of the same class  Person married to person  Part is made using parts The Domain Model Class Diagram  Class o A 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 (words run together and second word is capitalized) Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Domain Model Class Diagram Ex:  A customer places zero or more order  An order is placed by exactly one customer  An order consists of one or more order items  An order item is part of exactly one order UML Notation for Multiplicity Domain Model Class Diagram for a bank with many branches Association class  An association that is treated as a class in a many to many association because it has attributes that need to be remembered (such as grade) Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896  The association class is the same “thing” as the association itself More Complex Issues about Classes: Generalization/Specialization Relationships  Generalization/Specialization o A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy  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 classes inherit characteristics of the more general superclass: Inheritance for RMO Three Types of Sales Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 Abstract class— a class that allow subclasses to inherit characteristics but never gets instantiated. In Italics (Sale above) Concrete class— a class that can have instances  Semantics o A Motor Vehicle can be one of the following types: o A Car is a type of Motor Vehicle Inheritance for the Bank with Special Types of Accounts (Example of account attributes) A SavingsAccount has 4 attributes A CheckingAccount Has 5 attributes Note: the subclasses inherit the associations, too A Customer (custId, custName) can have 1 or more Orders. Downloaded by jeff thrid ([email protected])  lOMoARcPSD|40733896 An Order (orderNo, orderDate ) must have 1 and only 1 Customer An Order (orderNo, orderDate ) can be for 1 or more Items. An Item (itemId, itemDescription,listPrice) can appear on 1 or more Orders. For every Item on every Order there is a salePrice and a qtySoldAmt An Order (orderNo, orderDate ) can be for 1 or more Items. An Item (itemId, itemDescription,listPrice) can appear on 1 or more Orders. For every Item on every Order there is a salePrice and a qtySoldAmt Instead of an Association Class association we can represent this with the following model. Both are logically and functionally the same. Both would implemented and work the same – just modelled slightly differently. Downloaded by jeff thrid ([email protected])