Unit_4 Domain Modeling

Unit_4 will focus on a key concept that defines requirements: THINGS in the problem domain of system users. We first can also relate THINGS to data entities or domain classes like when we think about USE CASES. THINGS define the sources for the tables used in a relational database management system. Most approaches to system development include identifying and modeling data entities or domain classes as an important task in the analysis activity DEFINE FUNCTIONAL REQUIREMENTS. 
THINGS ->> Domain classes or data entities that end users deal with when they do their work- for example, products, sales, shippers, shipments, and customers,(as they are referred to in the context of a system's problem domain.)
PROBLEM DOMAIN->>A specific area of the user's business that is included within the scope of the new system . The new system involves working with and remembering these THINGS.
More often than not THINGS are related to the people who interact with the system or to the other stakeholders. [ a customer is a person who places an order BUT the system needs to store information about that customer, so a customer is also a thing in the problem domain. HOWEVER the system may need to store information about products, shipments, and warehouses, THESE ARE NOT!! persons. 
The two techniques for identifying the important THINGS in the problem domain that we will address are : the brainstorming technique and the noun technique.

The above cardinality constraint on the Order data entity indicates that there can be ONE OR MANY ORDERS .

 Generalization/Specialization Association

An Attribute whose value uniquely identifies an object is called a KEY ATTRIBUTE

The number of associations that occur among specific things in an entity relationship diagram is called CARDINALITY

In the traditional approach to system development, the system stores information about DATA ENTITIES

AN ASSOCIATION RELATIONSHIP would not be an appropriate way to describe a relationship between an employee and his/her manager,whereas, UNARY RELATIONSHIP BINARY RELATIONSHIP AND GENERALIZATION/SPECIALIZATION RELATIONSHIP would be appropriate. 

A class that represents a many-to-many association between two other classes is called an ASSOCIATION CLASS

If we modeled a "sale" and the "sale items" with a whole-part relationship, it would be best described as A COMPOSITE RELATIONSHIP.

In a generalization/specialization relationship, it would not make sense for a class at the bottom of the hierarchy to be an ABSTRACT class

Inheritance describes a condition between classes where classes share some attributes. 

Unit_3 SYSTEMS ANALYSIS AND DESIGN

Unit3 Analysis and Design

An extensive amount of information is required to properly define the system's functional and nonfunctional requirements. Techniques for documenting the functional requirements by creating models is part of the analysis activity DEFINE FUNCTIONAL REQUIREMENTS, although analysis activities are actually done in parallel and in each iteration of the project. All new approaches to system development begin the requirements modeling process with the concept of a use case, an activity the system performs, usually in response to a request by a user. Two techniques recommended for identifying use cases: the user goal technique and the event decomposition technique. CRUD is also often used to validate and enhance the list of use cases. The USER GOAL TECHNIQUE is to ask users to describe their goals for using the new or updated system. First thing the analyst does is identify all the users and conduct a structured interview with each user. The analyst would guide the user to identify specific ways that a computer system can help the user to perform the assigned tasks. the objective is to identify how a system can improve the user's performance and productivity.SUBSIDIARY GOALS might include streamlining tasks the user currently performs or enabling the user to perform new tasks that are not possible or practical with the current system. The analyst documents these as use cases as they are uncovered. often the user requires guidance from the analyst to think outside the box about the the ways they currently approach their jobs. Focus groups might be formed to uncover the wants and needs of potential customers. THE STEPS FOR IDENTIFYING USE CASES:

1. IDENTIFY ALL THE POTENTIAL USERS FOR THE NEW SYSTEM.

2. CLASSIFY THE POTENTIAL USERS IN TERMS OF THEIR FUNCTIONAL ROLE(SHIPPING, MARKETING, SALES)

3. FURTHER CLASSIFY POTENTIAL USERS BY ORGANIZATIONAL LEVEL (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. START WITH GOALS THEY CURRENTLY HAVE AND THEN GET THEM TO IMAGINE INNOVATIVE FUNCTIONS THEY THINK WOULD ADD VALUE. ENCOURAGE THEM TO STATE EACH GOAL IN THE IMPERATIVE VERB-NOUN FORM SUCH AS ADD CUSTOMER, UPDATE ORDER, AND PRODUCE MONTH END REPORT. 

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. 

The most comprehensive technique for identifying use cases is the EVENT DECOMPOSITION TECHNIQUE this technique begins by identifying all the business events that will cause the information system to respond, and each event leads to a use case. ACTOR AN EXTERNAL AGENT; A PERSON OR GROUP THAT INTERACTS WITH THE SYSTEM BY SUPPLYING OR RECEIVING DATA.TO IDENTIFY THE KEY EXTERNAL EVENTS, THE ANALYST FIRST TRIES TO IDENTIFY ALL THE EXTERNAL AGENTS THAT MIGHT WANT SOMETHING FROM THE SYSTEM. A CLASSIC EXAMPLE IS A CUSTOMER.

AUTOMATION BOUNDARY: DEFINES THE BORDER BETWEEN THE COMPUTERIZED PROTIO OF THE APPLICATION AND THE PEOPLE OPERATING THE APPLICATION. IT IS SHOWN AS A RECTANGLE CONTAINING THE USE CASE/ THE BOUNDARY BETWEEN THE COMPUTERIZED PORTION OF THE APPLICATION AD THE USERS WHO OPERATE THE APPLICATION BUT ARE PART OF THE TOTAL SYSTEM. 

ACTOR AN EXTERNAL AGENT; A PERSON OR GROUP THAT INTERACTS WITH THE SYSTEM BY SUPPLYING OR RECEIVING DATA.TO IDENTIFY THE KEY EXTERNAL EVENTS, THE ANALYST FIRST TRIES TO IDENTIFY ALL THE EXTERNAL AGENTS THAT MIGHT WANT SOMETHING FROM THE SYSTEM. A CLASSIC EXAMPLE IS A CUSTOMER.

AUTOMATION BOUNDARY: DEFINES THE BORDER BETWEEN THE COMPUTERIZED PROTIO OF THE APPLICATION AND THE PEOPLE OPERATING THE APPLICATION. IT IS SHOWN AS A RECTANGLE CONTAINING THE USE CASE/ THE BOUNDARY BETWEEN THE COMPUTERIZED PORTION OF THE APPLICATION AD THE USERS WHO OPERATE THE APPLICATION BUT ARE PART OF THE TOTAL SYSTEM. 

BRIEF USE CASE DESCRIPTIONS: It is important to recognize that this list of use cases will continue to evolve as the project progresses. Additional use cases will be added some might be eliminated, and some might be combined. It is helpful to immediately describe some of the details of each use case, preferable in one sentence. this brief description is usually expanded to record more to the details when the developers are designing and implementing the use case. In short, often a one-sentence description that provides a quick overview of a use case. 

CRUD TECHNIQUE: An important technique used to validate and refine use cases. The acronym for Create, Read or Report, Update, and Delete, THe analyst starts by looking at the types of data stored by the system which are modeled as data entities or domain classes. 

ELEMENTARY BUSINESS PROCESSES (EBPs): THE MOST FUNDAMENTAL TASKS IN BUSINESS PROCESSES-An EBP is a task that is performed by one person in one place in response to a business event, adds measurable business value and leaves the system and its data in a stable and consistent state. 

EVENT: An event occurs at a specific time and place, can be described and should be remembered by the system. Events drive or trigger all processing that a system does, so listing events and analyzing them makes sense when you need to define system requirements by identifying use cases. 

EVENT DECOMPOSITION TECHNIQUE: THE MOST COMPREHENSIVE TECHNIQUE FOR IDENTIFYING USE CASES IS THE EVENT DECOMPOSITION TECHNIQUE.  it begins by identifying all the business events that will cause the information system to respond and each event leads to a use case. 

EXTERNAL EVENT: An event that occurs outside the system- usually initiated by an external agent or actor. An external agent( or actor) is a person or organizational unit that supplies or receives data from the system To identify the key external events, the analyst first tries to identify all the external agents that might want something from the system . 

<<INCLUDES>> RELATIONSHIP: A relationship between use cases in which one use case is stereotypically included within the other use case

PERFECT TECHNOLOGY ASSUMPTION: States that events should be included during analysis only if the system would be required to respond under perfect conditions. By pretending that technology is perfect, analysts can eliminate events like" time to back up the database" because they can assume that the disk will never crash. Again during design the project team adds these controls because technology is obviously not perfect. 

STATE EVENT: An event that occurs when something happens inside the system that triggers the need for processing. State events are also called Internal events. 

SYSTEM CONTROLS: Are checks or safety procedures put in place to protect the integrity of the system.

TEMPORAL EVENT: An event that occurs as a result of reaching a point in time. 

USE CASE : An activity that the system performs, usually in response to a request by a user. 

USE CASE DIAGRAM: THe UML model used to graphically show use cases and their relationships to actors.

USER GOAL TECHNIQUE: Is to ask users to describe their goals for using the new or updated system. The analyst first identifies all the users and then conducts a structured interview with each user. 

Unit 2

Develop an activity diagram based on the following narrative. Note any ambiguities or questions that you have as you develop the model. If you need to make assumptions, also note them. The shipping department receives all shipments on outstanding purchase orders. When the clerk in the shipping department receives a shipment, he or she finds the outstanding purchase order for those items. The clerk then sends multiple copies of the shipment packing slip. One copy goes to
John and Jacob, Inc.: Online Trading System John and Jacob, Inc. is a regional brokerage firm that has been successful over the last several years. Competition for customers is intense in this industry. The large national firms have very deep pockets, with many services to offer clients. Severe competition also comes from discount and Internet trading companies. However, John and Jacob has been able to cultivate a substantial customer base from upper- middle-income clients in the northeastern United States. To maintain a competitive edge with its customers, John and Jacob is in the process of modernizing its online trading sys- tem. The modernization will add new features to the existing system and expand the range of interfaces beyond desktop and laptop computers to include tablet computers and Purchasing, and the department updates its records to indicate that the purchase order has been ful- filled. Another copy goes to Accounting so a pay- ment can be made. A third copy goes to the requesting in-house customer so he or she can receive the shipment. After payment is made, the accounting depart- ment sends a notification to Purchasing. After the customer receives and accepts the goods, he or she sends notification to Purchasing. When Purchasing receives these other verifications, it closes the pur- chase order as fulfilled and paid.

List and briefly describe the six information gathering techniques.

       Interview users and other stakeholders- an effective way to understand business functions and business rules
Distribute and collect questionnaires- enables analysts to collect information from a large number of stakeholders
Review inputs, outputs and documentation- internal documentation and external journals and studies.
Observe and document business procedures- in order to understand exactly what goes on in the business and business functions.
Research vendor solutions- consult other firms to see if they have already solved your business' problems. 
Collect active user comments and suggestions- user feedback. 


https://www.openproject.org/
https://github.com/opf/openproject/archive/master.zip

ACTIVITY DIAGRAM :describes user (or system) activities, 
the person who does each activity, and the sequential flow of these 
activities.  
APPLICATION ARCHITECTURE: The organization and construction
of software resources to implement an organization's information
systems.
CLIENT: Person or group that provides funding for a system development project. 
CLOSED-ENDED QUESTIONS : Questions that elicit specific facts.
DESIGN CONSTRAINTS: Restrictions to which the hardware and software must adhere.
EXECUTIVE STAKEHOLDERS: persons who don't interact directly with the system but 
who either use information produced by the  system or have a significant financial 
or other interest in its operation and success.
EXTERNAL STAKEHOLDERS : Persons outside the organization"s control and influence who interact with the system or have a significant interest in ints operation or success. 
FUNCTIONAL REQUIREMENTS : The activities the the system must perform.

Furps is an acronym that stands for functionality, usability, reliability, performance and security.
FURPS -> A requirements classification framework( acronym stands for functionality, usability, reliability, performance, and security.)

FURPS+: an extension of FURPS that includes design constraints as well as implementation, interface, physical and supportability requirements. 
GRAPHICAL MODELS: System models that use pictures and other graphical elements. Graphical models make it easier to understand complex relationships that are difficult to follow when described as a list or narrative.
IMPLEMENTATION REQUIREMENTS: describe constrains such as required programming languages and tools, documentation method and level of detail, and a specific communication protocol for distributed components. 
INTERFACE REQUIREMENTS: describe interactions among systems.
INTERNAL STAKEHOLDERS : are those within the organization who interact with the system or have a significant interest in its operation or success. You may be tempted to define internal stakeholders as employees or any organization but some organizations such as nonprofits and educational institutions have internal users ( volunteers and students ) who are not employees. 
MATHEMATICAL MODELS: System models that describes requirements numerically or as mathematical expressions.
MODEL: A representation of some aspect of the system being built. 
NONFUNCTIONAL REQUIREMENTS: Are characteristics of the system other than those activities it must perform or support.
WORKFLOW: The sequence of processing steps that completely handles one business transaction or customer request. Workflows may be simple or complex. Complex workflows can be composed of dozens or hundreds of processing steps and may include participants from different parts of an organization. 
USABILITY REQUIREMENTS Operational characteristics related to users such as the user interface, related work procedures, online help and documentation Additional requirements might include menu format, color schemes, use of the organization's logo and multilingual support
UNIFIED MODELING LANGUAGE (UML): Standard set of Model constructs and notations defined by the Object Management Group. By using UML analysts and end users are able to depict and understand a variety of specific diagrams used in a system development project. Violet is a UML editor with these benefits: Very easy to learn and use. Draws nice-looking diagrams. Completely free. Cross-platform. Violet is intended for developers, students, teachers, and authors who need to produce simple UML diagrams quickly
TEXTUAL MODELS : test-based system models such as memos, reports, narratives and lists, Analysts use such textual models as memos, reports, narratives and lists to describe requirements that are detailed and are difficult to represent in other ways. narrative description is often the best way to initially record information gathered verbally from stakeholders, such as during an interview. In many cases, narratives and other textual models are later converted into a graphical format.
TECHNOLOGY ARCHITECTURE: A set of computing hardware, network hardware and topology, and system software employed by an organization. 
SYSTEM REQUIREMENTS : The activities a system must perform or support and the constraints that the system must meet.
SYNCHRONIZATION BAR: Activity diagram component the either splits a control path into multiple concurrent paths or recombines concurrent paths. The heavy solid line is a synchronization bar.
SWIMLANE HEADING : An activity diagram column containing all activities for a single agent or organizational unit. The swimlane heading represents an agents who performs the activities, it is common in a workflow to have different agents ( people) performing different steps of the workflow process, the swimlane symbol divides the workflow activities into groups showing which agent performs which activity 
SUPPORTABILITY REQUIREMENTS: Describe how a system is installed, configured, monitored and updated. Example might be download of updates from a support server. 
STAKEHOLDERS: Persons who have an interest in the successful implementation of the system. Stakeholders are your primary source of information for your system requirements. 
SECURITY REQUIREMENTS: Requirements that describe how access to the application will be controlled and how data will be protected during storage and transmission. 
RELIABILITY REQUIREMENTS : Requirements that describe system dependability. 
PHYSICAL REQUIREMENTS: Characteristics of hardware such as size, weight, power consumption, and operating conditions. 
PERFORMANCE REQUIREMENTS: Operational characteristics related to measures of workload, such as the throughput and response time. 
OPERATIONAL STAKEHOLDERS: Persons who regularly interact with a system in the course of their jobs or lives. 
OPEN-ENDED: QUESTIONS QUESTIONS THAT ENCOURAGE DISCUSSION OR EXPLANATION
 Unit 2 Practice Quiz Overview
Technology architecture->Hardware,network , system software
Application Architecture -> SOftware, program language and development tools, User-Interface technology
Nonfunctional requirements -> Characteristics of the system other than the business procedures it must support. 
FURPS-> functionality, usability, reliability, performance, security
MODEL-> A representation of some aspect of the system being built. 
UML -> Unified Modeling Language
Technical StakeHolders -> A group that provides direction for the configuration of the new system in the existing computing environment. 
Closed-Ended Questions-> Questions that have simple, definitive answers
->->During a fact finding interview it is important to probe to get sufficient details.
->->Every successful Interview requires preparation.