SIAA MIDTERM 312

DATA STORAGE FORMATS

·       Files - A data file contains an electronic list of information that is formatted for a particular transaction, and the information is changed and manipulated by programs that are written for those purposes.

o   Master files store core information that is important to the business and, more specifically, to the application, such as order information or customer mailing information.

o   Look-up files contain static values, such as a list of valid codes or the names of the U.S. states. Typically, the list is used for validation.

o   A transaction file holds information that can be used to update a master file. The transaction file can be destroyed after changes are added, or the file may be saved in case the transactions need to be accessed again in the future.

o   An audit file records “before” and “after” images of data as the data are altered, so that an audit can be performed if the integrity of the data is questioned.

·       Database - A database is a collection of

groupings of information that are related to each other in some way (e.g., through common fields). Logical groupings of information could include such categories as customer data, information about an order, and product information.

o   Legacy Database - The name legacy database is given to those databases which are based on older, sometimes outdated technology that is seldom used to develop new applications.

o   Relational Database - A relational database is based on collections of tables, each of which has a primary key—a field(s) whose value is different for every row of the table. The tables are related to each other by the placement of theprimary key from one table into the related table as a foreign key.

o   Object Database - The basic premise of object orientiation is that all things should be treated as objects that have both data (attributes) and processes (behaviors). An object changes or accesses its own attributes only through its behaviors. Objects may communicate with each other for information or certain actions.

o   Multidimensional Database - A multidimensional database is a type of relational database that is used extensively in data warehousing. Data warehousing is the practice of taking data from a company’s transaction processing systems, transforming the data (e.g., cleaning them up, totaling them, aggregating them), and then storing the data for use in a data warehouse (i.e., a large database) that supports decision support systems (DSS).

·       Selecting a Storage Format - Each of the file and database data storage formats has its strengths and weaknesses, and no one format is inherently better than the others. In fact, sometimes, a project team will choose multiple data storage formats (e.g., a relational database for one data store, a file for another, and a multidimensional database for a third).

MOVING FROM LOGICAL TO PHYSICAL DATA MODELS

·       Change entities to tables or files -Beginning with the logical entity relationship diagram, change the entities to tables or files and update the metadata.

·       Change attributes to fields - Convert the attributes to fields and update the metadata.

·       Add primary keys - Assign primary keys to all entities.

·       Add foreign keys - Add foreign keys to represent the relationships among entities.

·       Add system-related components - Add system-related tables and fields.

OPTIMIZING DATA STORAGE

-          The optimization methods will vary with the format that you select; however, the basic concepts will remain the same. Once you understand how to optimize a particular type of data storage, you will have some idea as to how to approach the optimization of other formats.

Optimizing Storage Efficiency - The most efficient tables in a relational database in terms of storage space have no redundant data and very few null values, because the presence of these suggest that space is being wasted (and more data to store means higher data storage hardware costs).

Optimizing Access Speed - After you have optimized your data model design for data storage efficiency, the end result is data that are spread out across a

number of tables. When data from multiple tables must be accessed or queried, the tables first must be joined together.

Estimating Storage Size - Even if you have

denormalized your physical data model, clustered records, and created indexes appropriately, the system will perform poorly if the database server cannot handle its volume of data. Therefore, one last way to plan for good performance is to apply volumetrics, which means estimating the amount of data that Optimizing Data Storage 433 the hardware will need to support.

IMPLEMENTATION

·       The implementation phase consists of developing and testing the system’s software, documentation, and new operating procedures. These topics are presented in this chapter.

Managing the Program Process - In order to ensure that the process of programming is conducted

successfully, we discuss several tasks that the project manager must do to manage the programming

effort: assigning programming tasks, coordinating the activities, and managing the programming schedule.

o   Assigning Programming Tasks - During project planning (Chapter 2), the project manager identified the programming support required for constructing the system in terms of the numbers and skill levels of programmers. Now the project manager must assign program modules to the programming staff.

o   Coordinating Activities - Coordination can be done through both high-tech and low- tech means. The simplest approach is to have a weekly project meeting to discuss any changes to the system that have arisen during the past week—or just any issues that have come up.

o   Managing the Schedule - The time estimates that were produced during the initial planning phase and refined during the analysis and design phases must almost always be refined as the project progresses during construction, because it is virtually impossible to develop an exact assessment of the project’s schedule.

TESTING

Test Planning - A test plan often has 20 to 30 pages, with a separate page for each individual test in the plan. Each individual test has a specific objective, describes a set of very specific test cases to examine, and defines the expected results and the actual results observed.

Unit Test - The purpose of a unit test is to ensure that the module or program performs its function as defined in the program specification. Unit testing is performed after the programmer has developed and tested the code and believes it to be error free.

Integration Test - Integration tests assess whether a set of modules or programs that must work together do so without error. They ensure that the interfaces and linkages between different parts of the system work properly.

System Tests - System tests are usually conducted by the systems analysts to ensure that all modules and programs work together without error. System testing is similar to integration testing, but is much broader in scope.

Acceptance Tests - Acceptance tests are done

primarily by the users with support from the project team. The goal is to confirm that the system is complete, meets the business needs that prompted the system to be developed, and is acceptable to the users.

DEVELOPING DOCUMENTATION

Types of Documentation:

·       Designing Documentation Structure - The general structure used in most online documentation, whether reference documents, procedures manuals, or tutorials, is to develop a set of documentation navigation controls that lead the user to documentation topics.

·       Writing Documentation Topics – Topics typically start with very clear titles, followed by some introductory text that defines the topic, and then provide detailed, step-by- step instructions on how to perform what is being described (where appropriate).

·       Identifying Navigation Terms - The table of contents is usually the most straightforward, because it is developed from the logical structure of the documentation topics, whether reference topics, procedure topics, or tutorial topics.

OBJECT-ORIENTED DESIGN

-          Object-oriented systems focus on capturing the structure and behavior of information systems in little modules that encompass both data and processes. These little modules are known as objects.

Class and Objects - A class is the general template we use to define and create specific instances, or objects. An object is an instantiation of a class. In other words, an object is a person, place, event, or thing about which we want to capture information.

Methods and Messages - Methods implement an object’s behavior. A method is nothing more than an action that an object can perform. Methods are very much like a function or procedure in a traditional programming language such as C, COBOL, or Pascal. Messages are information sent to objects to trigger methods. A message is essentially a function or

procedure call from one object to another object.

Encapsulation and Information Hiding - Encapsulation is simply the combining of process and data into a single entity. Object-oriented approaches combine process and data into holistic entities (objects). The principle of information hiding suggests that only the information required to use a software module be published to the user of the module.

Inheritance - Typically, classes are arranged in a hierarchy whereby the superclasses, or general

classes, are at the top, and the subclasses, or specific classes, are at the bottom. Subclasses inherit the attributes and methods from the superclass above them. That is, each subclass contains attributes and methods from its parent superclass.

Polymorphism and Dynamic Binding - Polymorphism means that the same message can be interpreted differently by different classes of objects. For example, inserting a patient means something different than inserting an appointment. Polymorphism is made possible through dynamic binding. Dynamic, or late, binding is a technique that delays identifying the type of object until run-time. As such, the specific method that is actually called is not chosen by the object-oriented system until the system is running.

OBJECT-ORIENTED SYSTEM ANALYSIS AND DESIGN

·       Use Case Driven - Use case driven means that use cases are the primary modeling tool employed to define the behavior of the system. A use case describes how the user interacts with the system to perform some activity, such as placing an order, making a reservation, or searching for information.

·       Architecture Centric - Architecture centric means that the underlying architecture of the evolving system drives the specification, construction, and documentation of the system.

·       Iterative and Incremental - Object-oriented approaches emphasize iterative and incremental development that undergoes continuous testing throughout the life of the project. Each iteration of the system brings the system closer and closer to the final needs of the users.

Benefits of Object-Oriented Systems Analysis and Design:

Class, Objects, Methods, and Messages

·       A more realistic way for people think about their business.

·       Highly cohesive units that contain both data and processes

Encapsulation and Information Hiding

·       Loosely coupled units

Inheritance

·       Allows us to use classes as standard templates from which other classes can be built

Polymorphism

·       Minimal messaging that is interpreted by objects themselves

Use case driven

·       Allows users and analysts to focus on how a user will interact with the system to perform a single activity

Architecture centric and functional, static, and dynamic views

·       Viewing the evolving system from multiple points of view

Iterative and incremental development

·       Continuous testing and refinement of the evolving system

UNIFIED MODELING LANGUAGE, VERSION 2.0

·       The objective of the Unified Modeling Language is to provide a common vocabulary of object-based terms and diagramming techniques that is rich enough to model any systems development project from analysis to design.

Use Case Diagram

·       Use cases are the primary drivers for all of the UML diagramming techniques. The use case communicates at a high level what the system needs to do, and each of the UML diagramming techniques build upon this by presenting the functionality in different ways, each view having a different purpose.

Elements of a Use Case Diagram

·       A use case diagram illustrates in a very simple way the main functions of the

system and the different kinds of users who will interact with it:

An actor

·       Is a person or system that derives benefit from and is external to the system. Is labeled with its role.

·       Can be associated with other actors by a specialization/superclass association, denoted by an arrow with a hollow arrowhead.

·       Is placed outside the system boundary

A use case

·       Represents a major piece of system functionality.

·       Can extend another use case.

·       Can use another use case.

·       Is placed inside the system boundary.

·       Is labeled with a descriptive verb–noun phrase

A system boundary

·       Includes the name of the system inside or on top.

·       Represents the scope of the system.

An association relationship

·       Links an actor with the use case(s) with which it interacts.

CREATING A USE CASE DIAGRAM

Identify Use Cases - Before a use case diagram can be created, it is helpful to go through the process of identifying the use cases that correspond to the system’s major functionality and putting together the use case documentation for each of them.

Draw the System Boundary - First, place a box on the use case diagram to represent the system, and place the system’s name either inside or on top of the box. This will form the border of the system, separating use cases from actors.

Place the Use Cases on the Diagram - The next step is to add the use cases inside the system boundary. There should be no more than six to eight use cases on the model, so if you identify more than eight, you should group together the use cases into packages (i.e., logical groups of use cases) to make the diagrams easier to read and keep the models at a reasonable level of complexity.

Identify the Actors - Once the use cases are placed on the diagram, you will need to identify the actors. Add Association Relationships - The last step is to draw lines connecting the actors with the use cases with which they interact. No order is implied by the diagram, and the items you have added along the way do not have to be placed in a particular order; therefore, you may want to rearrange the symbols a bit to minimize the number of lines that cross so that the diagram is less confusing.

CLASS DIAGRAM

•            The class diagram is a static model that supports the static view of the evolving system. It shows the classes and the relationships among the classes that remain constant in the system over time.

Elements of a Class Diagram:

Class - The main building block of a class diagram is the class, which stores and manages information in the system.

Associations - A primary purpose of the class

diagram is to show the associations, or relationships, that classes have with one another. These are depicted on the diagram by lines drawn between classes.

Generalization and Aggregation - Generalization shows that one class (subclass) inherits from another class (superclass), meaning that the properties and operations of the superclass are also valid for objects of the subclass. Aggregation is used when classes actually comprise other classes.

Simplifying Class Diagrams

·       When a class diagram is drawn with all of the classes and associations for a real-world system, the class diagram can become very complex. When this occurs, it is sometimes necessary to simplify the diagram by using a view to limit the amount of information displayed.

·       Views are simply subsets of information contained in the entire model.

Creating a Class Diagram:

·       Creating a class diagram (like any UML diagram) is an iterative process whereby the analyst starts by drawing a rough version of the diagram and then refines it over time.

Identify Classes - The steps for creating a class diagram are quite similar to the steps that we

learned to create an ERD. First, you will need to identify what classes should be placed on the

diagram. Remember, like ERDs, class diagrams show the classes that are needed for the system as a whole.

Identify Attributes and Operations - Hopefully, you determined that the class diagram will need to include classes that represent Available Tunes, Favorites, Interests, Promotions, and Customer.

Draw Associations between the Classes - Associations are added to the class diagram by drawing association lines. Go through each class and determine other classes to which it is associated, the name of the association (or the role it plays), and the number of instances that can participate in the association.

SEQUENCE DIAGRAM

·       The next major UML diagramming technique is the sequence diagram. A sequence diagram illustrates the objects that participate in a use case and the messages that pass between them over time for one use case.

Elements of a Sequence Diagram:

An actor

·       Is a person or system that derives benefit from and is external to the system.

·       Participates in a sequence by sending and/or receiving messages. Is placed across the top of the diagram.

An object

·       Participates in a sequence by sending and/or receiving messages.

·       Is placed across the top of the diagram.

A lifeline

·       Denotes the life of an object during a sequence.

·       Contains an X at the point at which the class no longer interacts.

A focus of control

·       Is a long narrow rectangle placed atop a lifeline.

·       Denotes when an object is sending or receiving messages.

A message

·       Conveys information from one object to another one.

Object destruction

·       An X is placed at the end of an object’s lifeline to show that it is going out of existence.

Creating a Sequence Diagram:

Identify Objects - The first step is to identify instances of the classes that participate in the sequence being modeled; that is, the objects that interact with each other during the use case sequence.

Add Messages - Next, draw arrows to represent the messages being passed from object to object, with the arrow pointing in the message’s transmission

direction.

Place Lifeline and Execution Occurrences - Last, you will need to show when objects are participating in the sequence. A vertical dotted line is added below each object to represent the object’s existence during the sequence, and an X should be placed below objects at the point on the lifeline where they are no longer interacting with other objects.

BEHAVIORAL STATE MACHINE DIAGRAM

Elements of a Behavioral State Machine Diagram:

A state

·       Is shown as a rectangle with rounded corners.

·       Has a name that represents the state of an object

An initial state

·       Is shown as a small filled-in circle.

·       Represents the point at which an object begins to exist.

A final state

·       Is shown as a circle surrounding a small, solid filled-in circle (bull’s-eye).

·       Represents the completion of activity

An event

·       Is a noteworthy occurrence that triggers a change in state.

·       Can be a designated condition becoming true, the receipt of an explicit signal from one object to another, or the passage of a designated period.

·       Is used to label a transition.

A transition

·       Indicates that an object in the first state will enter the second state.

·       Is triggered by the occurrence of the event labeling the transition.

·       Is shown as a solid arrow from one state to another, labeled by the event name.

Creating a Behavioral State Machine Diagram

Identify the States - The first step is to identify the various states that a selected tune will have over its lifetime. This information is gleaned from reading the use case reports, talking with users, and relying on the requirements-gathering techniques that you learned about in Chapter 3.

Identify the Transitions - The next step is to identify the sequence of states that a selected tune object will pass through during its lifetime and then determine exactly what causes each state to occur.