In the analysis phase, Data Flow Diagrams (DFDs) ~ otherwise referred to as bubble charts, [business] process Models, work flow diagrams, function diagrams” — are used to graphically depict how data moves sequentially from one to step to another in the existing system, and how the data is transformed in the Process. DFDs are an invaluable modelling tool, as they help analysts to better understand what is going on un System by depicting how data associated with a particular process flows through the system.?? As they are intuitive, DEDs can help system users validate that the analyst has depicted the system correctly.32 ADFD has four basic components: 1, Process — This is an activity which sees to input data being transformed into output data or sees to some decision being made based on the input.* In a DFD, Processes are represented by rounded rectangles, ovals, or circles; whichever you chose, you must remain consistent.® Processes are labelled with the name of the process as a verb-object phrase or in some cases the name of the system, and a process number for easy referencing.2? Calculate Report-Generating Retirement Fund System 2. Source ~ This is an entity which is external to the system and either provides it with input data (source) or receives output data from it (sink).3! In a DFD, a source is represented by a square and is labelled with the source’s name.2? Customer, 833. Data Flow~ This depicts the movement of data through the system. Data flows are represented by arrows showing where the data is coming from (tail end) and where it is going to (arrow end) and are labelled with the name of the data that is being transferred as a noun.?? Employees’ Personal Information —— Data Store — This depicts a repository for data and information in a system, such as a filing cabinet, check-book register or an electronic file.2! Data stores are represented by two-parallel lines or a compartmentalized rectangle with the right side opened, and is labelled with the name of the data store as a noun or the plural of the data items it is storing.2? Retirement Fund File pt Orders DFDs can be used to show how a system operates on the data it is presented with in different levels of detail: 1. Context-Level Diagram A context-level diagram is a top-level diagram which uses a single bubble (process) to represent the entire system, with data flow lines connecting it to external entities which might be interacting with the system or to external stores which are either providing data to the systems or receiving data from it.°? Application form Confirmation Letter Student Registration. system Rejection Letter 84Lower-Level Diagram Lower-level diagrams are used to represent the system in greater detail by zooming in on different processes and even their sub-processes."! A lower-level DFO is termed a “Level-n DFD”, where n is a positive integer depicting the level of detail being depicted; level-O DFDs show the highest-level view of view of the major processes in a system and the major interfaces with those processes, level-1 DFDs show the sub-processes to those processes, and so on. Application form Confirmation Student File Letter ‘Check Course File Student details Rejection ae, Letter cane coutseino availabilty 7 1 | Course File In order to create meaningful DFD’s, it is important to follow certain guidelines??: 1, Meaningful names should be chosen for processes, flows, stores and sources. 2. Process should be numbered to allow for easy referencing; it does not imply a sequence of activities, as processes in a system often occur synchronously. 3. Work towards a neat diagram, even if that means having to redraw it several times. 4. Ensure that the symbols you use to represent each element of the DFD remains consistent throughout the representation. 5. Avoid having processes where there are many inputs but no output, or there is output but no input. 6. Data cannot move directly from a source/sink to another source/sink; it must first go through a process. 7. Data cannot directly move from a source/sink to a data store, or vice versa; it must first go through a process. 8586 ha 8. Data cannot directly move between two data stores; it must first go throug! process. uy yasa 9. When connecting a process to a data store, avoid adding ‘request a 2 data flow to the data store, as this is not really data that will be rep Dati @ DFO; just add the data flow going from the data store to the process required data.ity-Relationship Diagrams (ERDs) An Entity-Relationship Diagrams (ERD) is a tool which is used to graphically represent the interactions which exist between entities in a system.? Whereas DFDs are more concerned with representing the processes of the system, ERDs are more focused on the representing in detail the data in the system.2? ERDs are concerned with highlighting the entities within a system and the relationships that exist between them. There are certain standard notations which your ERD must conform to, such as the Chen notation or the UML notation; CXC recommends you use either of these. An ERD has three basic components: 1. Entities These are real-world objects which are capable of unique existence and can be identified separately from another object; entities may be identified as a concrete noun such as STUDENT, CUSTOMER, HOSPITAL, or as an abstract noun such as COURSE or APPOINTMENT.*" In an ERD, an entity is represented by a rectangle labelled with the name of the entity. There are two types of entities: |. Strong Entities — A strong entity is an entity in which an instance of it can be universally differentiated from another instance, and does not need another entity to substantiate its existence. Strong entities have their own unique identifier" (see types of attributes below). Example: each individual in Jamaica is a strong entity who can theoretically exist without another entity such as a house or car; each person can be uniquely identified by a TRN. Strong entities are represented by a single-lined rectangle. 4 {2 PERSON Owns: VEHICLE Il. Weak Entities - A weak entity is an entity which needs a strong entity to substantiate its existence and any instance of the entity can only be differentiated from another within a very small scope; weak entities are identified by a discriminator* (see type of attributes below). Example: a payment made on a loan is a weak entity as without the payment being associated with a particular loan, it could not be identified; each payment 8788 made to a particular loan can be identified by a loan number. Whenever weak entities participate in relationships, the relationship is said to be mandatory (see types of relationships) and is also weak. Weak entities are represented by a double-lined rectangle." PAYMENT | It must be noted that a weak entity can be turned into a strong entity if the discriminator is adjusted to become a unique identifier, making the entity have a universally differentiating attribute. 2. Attributes These are characteristics of an entity, that is, they are facts about the entity you are inspecting. Example: FIRSTNAME, LASTNAME, TRN. In an ERD, an attribute is represented by an oval labelled with the name of the attribute and attached to the corresponding entity. There are different types of attributes: |. Single-Valued — This can only store one value" and is represented bya single-lined oval. Example: FNAME. a= PERSON, CD aD Owns M VEHICLE Il. Multi-Valued — This can store more than one values* and is represented by a double-lined oval. Example: EMAIL_ADDRESS, PHONES. This should only be used if the scenario explicitly states that an entity should be able to have more than one values for a particular attribute. aT? 2P= PERSON ‘Owns VEHICLE Ill, Derived - The value stored by this attribute is calculated from other attributes or entities and is represented by a broken-lined oval. Example: AGE. ‘d N—. course STUDENT IV. Composite — This attribute can be divided into subparts", that is, it has other attributes associated with it which serve to give it more details. Example: ADDRESS has STREET#, STREET_NAME, PARISH, COUNTRY associated with it. The other attributes are all connected to the main attribute. MEMBER Participates in EVENT V. Unique ~ This attribute is used to differentiate one strong entity from another and is represented by a solid underline beneath the name of the attribute. Example: TRN. VI. Discriminator — This attribute is used to differentiate one weak entity from another and is represented by a broken underline beneath the name of the attribute. Example: PAYMENT# 89. Relationships These describe a meaningful interaction/connection between entities. In a given scenario, they are usually identified as verbs associated with an entity. Example: DOCTOR treats PATIENT. In an ERD, a relationship is represented by a diamond labelled with the name of the relationship and attached to the corresponding entity/ies. When speaking about the relationships which exists between entities, there are several characteristics of the relation which must be considered: 1. Cardinality Cardinality refers to the number of instances of an entity that a particular entity can be associated with in a relationship. There are three logical cardinalities: |. One-to-one — this suggests that one instance of an entity may be related to no more than one instance of another entity". Example: a CHILD can only get one BICYCLE which will belong solely to them. In Chen’s notation, this cardinality is represented by lines connecting the relationship to all the entities, with a 1 above each of the lines.® 90Child Gets bicyCLE Il. One-to-many — this Suggests that an instance of entity A may be related to any number of instances (zero or more) of entity B but an instance of entity B may only be related to at most one instance of entity A. Example: a PERSON can own many VEHICLES but each vehicle can only have one owner. In Chen’s notation, this cardinality is represented by a solid line connecting the relationship to the entities, with the “one” entity having a 1 above its line, and the “many” entity have an M above its Pe BOD PERSON, ‘Owns VEHICLE Ill, Many-to-one — this suggests that an instance of entity A may be related to at most one instance of entity B, but an instance of entity B may be related to any number (zero or more) of instances of entity A" It is logically the same as the one-to-many cardinality, with the entities only being reversed.'V. Many-to-many ~ this suggests that any number of instances (zero or more) of entity A may be related to any number of instances (zero or more) of entity B.* Example: a COURSE can be taught by many LECTURERS and a LECTURER can teach many COURSES. In Chen’s notation, this cardinality is represented by solid lines connecting the relationship to all entities involved, each entity having an M or N above their connection to the relationship." LECTURER Teaches COURSE Precise constraints may also be placed on cardinalities so as to create a range for the number of associations one entity might make with another. Example: A LECTURER in a many-to-many relationship with 92COURSE signifies that they can theoretically teach an infinite number of courses and a course may be taught by an infinite number of lecturers. Realistically though, one may wish that a lecturer only teach a maximum of 3 courses for the semester and the course may only be taught by up to 5 lecturers for the semester. To represent this on the ERD, the notation “ny..n2" can be placed above the solid line, where ni represents the minimum value of the constraint and nz represents the maximum value; an Mis used where the maximum value is an unspecified number, example, 2..M.2 The following diagram depicts the above constraints being applied to our LECTURER-COURSE example: Lecturer | 2 0.21 course 2. Degree of the Relationship The degree of a relationship refers to the number of entities participating in said relationship. The three main degrees usually referred to are: |. Unary - This relationship involves only one entity. It simply means that an instance of an entity is in a relationship with another instance of the same entity. Seeing that each instance of the entity will be performing a separate role, the arrows connecting the entity to the relationship will be labelled accordingly. Example: a STUDENT who is a class treasurer collects dues from STUDENTS who are contributors. ‘ADDRESS, STUDENT Il, Binary - This relationship involves two entities. Example: a LECTURER is hired by only one DEPARTMENT at a COLLEGE. 9394 Goons) Ces GD | > DEPARTMENT M— Lecturer ML. Ternary ~ This relationship involves three entities. In this relationship, in order for entity C to participate, there must exist a specific relationship between entity A and entity B. Example: A STUDENT being assigned a PROJECT after being enrolled in a COURSE. PROJECT N STUDENT articipates I COURSE Ternary relationships can also be represented using aggregates. Aggregates represent a combination of a relationship and its entity/ies, and are treated as entities in their own right." Whilst any degree of relationships may be represented as an aggregate, they are usually used to represent unary and binary relationship. Aggregates can be used to store information about a relationship such as the date a STUDENT enrolls in a COURSE. In reference to the example above, in order for the student to be assigned a particular project, they need to be enrolled in a specific course. This can be represented as such: DATE. OUP DESCRIP. PROJECLID PROJECT STUDENT_ENROLLMENT STUDENT Enrolls in COURSE 3. Participation Whenever an instance of an entity is created, it may or may not be obliged to participate in a relationship with another entity. 1 Optional Participation — whenever there exists an instance of an entity, it may exist indefinitely without participating in the relationship. Example: a STUDENT attending a SCHOOL may or may not participate in a CLUB/SOCIETY. Optional participation is represented by a single line between the relationship and the entity having the option to participate. clue/ sruvent LM _ertcipates > 3 a SOCIETY 9596 Ml. Mandatory Participation - whenever there exists an instance of an entity, it must be participating in the relationship." Example: an ACCOUNT at a BANK must be associated with a CUSTOMER. Mandatory participation is represented by a double line between the relationship and the entity having the obligation to participate. Here are certain rules to follow when constructing ERDs: 1. Entity names should be labelled in the singular. Example: CUSTOMER, not CUSTOMERS. 2. In Chen’s notation, entities do not connect directly to each other and neither do 3. Every entity should have either a unique identifier or a discri 4 relationships. Only a relationship can join two or more entities. ator. If a potential attribute has information about it which you wish to store, represent it as an entity, setting the information about it as its attributes and forming a relationship with the entity it was going to be an attribute of." COOL ELELOOEect Models f you can recall from Unit 1, objects are representations of real world entities, allowing for both properties of the entity and activities the entity can do to be identified. In object modelling, the Properties of an object are represented by attributes, which describe particular aspects of the object. For a student object, one might need to store the name of the student, their age, date of birth and probably their grades as attributes. Activities the object can perform are represented as ‘methods. The methods the student object could have done on its data (stored in its attributes) might be to calculate their average grade, to display all their information or to calculate how much they owe for their school fee. Object modelling uses the Unified Modelling Language (UML) as the standard notation to diagrammatically represent objects that are identified in a system®, their constituent parts, how objects relate to each other, the processes actors play a role in, among others. Two of the most commonly used object models are: 1, Class Diagram In object modelling, the concept of a particular real world object is represented by a class and each occurrence of that class is an object. So, a particular class might be called Student to represent the student concept, but an object of the class might be called mary. This is somewhat similar to defining a structure called Student and creating a variable of the structure called mary; classes however encompass both data and the operations that can be performed on the data. Class diagrams offer a diagrammatic representation of the classes identified in a system and how they relate to each other. 9798 Class diagrams are represented by a rectangle divided into 3 sections: ClassName ~attributeName: datatype ~attributevame: datatype ~attributeame: datatype + methodName ():returntype + methodName (argument: datatype): returnType + methodName (argument: datatype, argument: datatype): returnType The first section identifies the class’ name, which is formatted to be in the centre. Class names are written in UpperCamelCase, with the first letter of every word being capitalized. The second section identifies the list of attributes the class has, which is formatted to be at the left. Variable attributes are written in lowerCamelCase, with first letter of every word being capitalized except for the first word. Constant attributes are written in ALL_CAPS, with an underscore separating each word. Attributes have different symbols preceding them specifying the level of access other classes have to them. Attributes that can be directly accessed by every class are said to be public and have the plus sign (+) preceding them; a class’ attributes should never be made public so as to preserve encapsulation. Attributes that cannot be accessed directly by any other class are said to be private and are preceded by a minus sign (-). Attributes that can be accessed directly by only their sub-classes are said to be protected and are represented by a pound sign (#); the attributes of super-classes should be made protected. The third section of the class diagram identifies the class’ methods, which is also left-aligned. Method names are written in lowerCamelCase. Preceding a method name is also a symbol specifying the level of access other classes have to the method; methods are normally declared public. Three common types of relationships between classes are: 1. Inheritance — this is the ability of one class to acquire the functionality of another class while adding functionalities of its own.!? The class inheriting attributes and methods from another class is called the child class/subclass, and the class providing the attributes and methods for inheritance is called the parent class/superclass, Example: In a particular system, you may identify a class called SpaReservation and another called GuestReservation. SpaReservation and GuestReservation both have some attributes andmethods that are similar. The similar elements could be put inside a class called Reservation, and the SpaReservation and GuestReservation classes could inherit these from the Reservation class, adding their unique attributes and methods to their own classes. As you may recall from Unit 1, classes can override methods they inherit; a Bird class might inherit 2 movel) method from an Animal class, which it overrides with a fly() method. To represent inheritance in a class diagram, a solid line ending in an unshaded arrow leads from the child class to the parent class’? (the arrowhead lands on the parent class). Reservation ‘client: Client H resDetalls: ReservationDetalls + Reservation () + dlsplayinfo(): vold + setClient (fName: string, IName: string): void + sethesDetalls(resStat string, esDat: ReservationStatus): vold + etClient (): Client + getResDetails (): ReservationDetails SpaReservation RoomReservation + spaService: string - appointmentNum: int room: string ~stayDuration: int + SpaReservation () + displayinfo(): void + setSpaService (spaServic + setAppointmentNum (apmntNum: int): void + getSpaservice (): string + getAppointmentNum (): Int + RoomReservation () + displayinfo(): void + setRoom (room: string): void + setStayDuration (stayDur: int: void + getRoom (): string + getStayDuration (): int 2. Association — this refers to the number of objects of a class that an object of another class can be related to. This is similar in concept to cardinality in ERDs. Classes in an association relationship are linked by a solid line with the cardinality symbols, notations and relationships placed on respective sides of the line, The following example shows that a library user can borrow zero to five books and each book can only be borrowed by one library user; the arrow beside the verb indicates the order in which to read. 99100 Refer to Cardinality in Entity-Relationship Diagrams (ERD) for more cardinality notations. Book: UbraryUser les string -————__———+ “ISBN: string name: UserName = barcode: string = 1ONum: string eBook os SPs 1 ibraryuser + displayinfo (): vold [> | tdisplayinto 0): void + setTitle (title: string): void + setName ((Name: string, + setISBN (ISBN: string): vold Name: string): vold + setBarcode () string + SetID (IDNum: string): void + getTitle (): string + getName (): UserName + BetISBN () string + get (): string + getBarcode (): string 3. Composition - this is a type of association relationship where every instance of class Ais related to one or more instances of class B. Seeing that class A is said to have one or more objects of class B, the relationship is also called an “has-a” relationship. Classes participating in a has-a relationship have a solid line connecting the two classes with a filled diamond on the has-a side, Cardinality notation may also be used to add more detail to the relationship. Building Room 2. Use Case Diagram A.use case diagram is a diagrammatic representation of the interactions that exist between a system and external entities such as other systems and users.>2 It depicts who will use the system and the precise processes they will be interacting with. Use case diagrams are used to convey only an overview of a system and have to be used in conjunction with others models which will reference its elements and therefore substantiate it.” One such model could be an activity diagram, which details the order which activities are performed in a process, something a use case diagram is incapable of. Ause case diagram consists of: 1. Use case — this is an activity that may occur in a particular process. Example: in an order process, a customer placing an order would be a use case, and so too would be the customer cancelling the order. Use cases are represented by ovals labelled with the name of the activity as a verb phrase. Il, Actors - this refers to any external entity that can interact with the system and exchange information with it. Examples of actors include customer, humidity sensor, time, and billing system. Actors are represented by stick figures labelled with their name, and are connected to their respective use case by a solid line. Use case diagrams, like many other models, include ways to represent inheritance, cardinality and special relationships called ‘include’ and ‘extend’. Inheritance and cardinality can be represented using similar symbols and notations like ERDs. The ‘include’ relationship is used to depict the idea that the steps included in one use case are also always included in another use case. The main use case is said to ‘include’ the subsequent use case, and has an unbroken line ending in an arrow leading from it to the included use case and is labelled with <>. The ‘extend’ relationship is used “to show that one use case may add functionality to another use case under certain circumstances”. The extension use case is said to extend the functionality of the base use case, and has an unbroken line ending in an arrow leading from it to the base use case and is labelled with <>. 101Customer Signup Process : " Declare Customer Details Lr sence Declare Coupon ences = 9 1 ° - i ee: Customer eerie Request Menu Catalogue “eens 102One inherent flaw of all graphical models used In the analysis phase Is that they lack @ certain amount of detall. It becomes necessary then that a repository be developed which stores detalled descriptions of all the data mentioned In the system models used.” The Data Dictionary, created by the analyst during detailed analysis", Is an alphabetic listing of the Items mentioned In the system models used, alongside their associated description, type of data (entity, relationship, data store etc.), and date that the data item was created,” Below is an example of an excerpt from a data dictionary: ‘A particular area of study which the course university offers Its students to partake Entity 4/5/2015 in for one semester. The unique identification number courses The ame aent Attribute 4ys/2015 The date of bith of the student in the poe eer ae Attribute 5/5/2015 ‘many-to-many relationship between Enrollsin the student and the courses they are Relationship 4/5/2015 taking Fame The first name of the student, Auribute asa0is The unique identification number po issued to the student by the university, Attribute ofera0NS iname The last name of the student. Attribute as/2015 et A person who ts reqitered 0 tke gay, agpune courses at the university. Dictionary entries are usually created and maintained by software programs. These software programs can also be integrated with other software tools which allow for system modelling, example: some CASE tools, so that whenever a name is entered for the first time, a dictionary entry is automatically created.” The data dictionary software may also be linked to other software used at other stages of the SDLC, allowing for everyone on the development team to have access to a central information store; this also allows for consistency in names used by the different members of the development team.>? 10