Please do it Yourself. You are supposed to write an SRS document of the system scenario given in the file named “Smart health system”. In the file the information about the system and its module which are to be made are discussed. You are supposed to make an SRS document of that system by writing only the first three sections of the SRS document. The File: Read it Smart Health Monitoring System As the name states Smart Health Monitoring System is a smart AI that calculates almost everything you need to take care of your health. The System helps with -BMI Level, -Diet Monitoring, -Diet Suggestions, -Footstep monitoring, -Sleep Suggestions, -Water Alarm. So the user has to just register into the system by giving his personal details and physical attributes and the rest, the system takes care of everything. The Food items with its fats, carbs and proteins level are already stored in the database and the user can also add new food, which will help the system to monitor the users diet and accordingly suggests. Modules: • Registration: The user has to register into the system with his basic details. • Login: The user has to login into the system keeping the data secure. • Profile: The user can see his profile and can update his physical attributes which also reflects on other things. • BMI: The system shows the user about his BMI level and status. • Diet Monitoring: The System calculates the daily take of the user in 3 criteria’s; Proteins, Fats and Carbohydrates. The User has to enter his daily intakes which helps him how much he has consumed and how much he should take. • Diet Suggestion: The System suggests the user what food he should consume. • Footsteps Monitoring: The System continuously calculates the footsteps and tells the user about his daily footsteps. • Sleep Suggestion: The System tells the user how much sleep he should get daily. • Water Alarm: The System tells the user how much water the user should intake and also alarms him by notifying him about how much water he should have consumed now. Software Requirements: • Windows XP, Windows 7(ultimate, enterprise) • Android Studio • SQL Server/Visual Studio Hardware Components: • Processor – i3 • Hard Disk – 5 GB • Memory – 1GB RAM • Android Phone with kitkat and higher. Advantages: • The User has to Login to use the app features. • The system guides the user about his diet intakes. • The System shows the bar of his intake level to let the user know about his limit. • System also suggests the user about the food he should have. • The system also acts as a Pedometer. • System lets the user know about his water and sleep intake. • Data Changes when the user updates his physical attributes. Disadvantages: • It requires an active internet connection. • The user should provide correct information to get the right output. Applications: • This system can be used by anyone young or old who needs to keep track and monitor their diet.

ANSWER:

1. INDEX OF THE CONTENTS • Introduction to the lab. • (Details of H/w & S/w to be used in the lab) • List of Programs (as per the syllabus of AKTU.) • Format of the lab record to be prepared by the students. • Steps to be followed ( for each practical ) • Sample Diagram/s • List/Details of the additional things. ( extra programs, projects etc. ) • Marking scheme INTRODUCTION TO THE LAB • Requirement of the lab • Hardware Requirements: Dual Core processor (2.0 GHz), 4 GB RAM, Standard keyboard and mouse, colored monitor. • Software Requirements: Rational Rose, Windows 7, Jupyter Notebook. This lab deals with the analysis and design of a software problem .the tool used in a lab is Rational Rose Enterprise Edition .This tool is used for a object oriented design of a problem. We draw a uml diagram in a rational rose which deals with the objects and classes in a system .The Unified Modeling Language or UML is a mostly graphical modeling language that is used to express designs. It is a standardized language in which to specify the artifacts and components of a software system. It is important to understand
2. 3. that the UML describes a notation and not a process. It does not put forth a single method or process of design, but rather is a standardized tool that can be used in a design process. The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.1 The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software Goals of UML The primary goals in the design of the UML were: 1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide a formal basis for understanding the modeling language. 5. Encourage the growth of the tools market.
3. 4. 6. Support higher-level development concepts such as collaborations, frameworks, patterns and components. 7. Integrate best practices. Why Use UML? As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Where Can the ML Be Used? The UML is intended primarily for software-intensive systems. It has been used effectively for such domains as 1. Enterprise information systems 2. Banking and financial services 3. Telecommunications 4. Transportation 5. Defense/aerospace 6. Retail 7. Medical electronics 8. Scientific 9. Distributed Web-based services
4. 5. The UML is not limited to modeling software. In fact, it is expressive enough to model non software systems, such as work-flow in the legal system, the structure and behavior of a patient health-care system, and the design of hardware. Introduction of all Diagrams to be drawn Using Rational Rose A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships). A diagram is a projection into a system. The UML includes nine such diagrams. 1. Class diagram A structural diagram that shows a set of classes, interfaces, collaborations, and their relationships 2. Object diagram A structural diagram that shows a set of objects and their relationships 3. Use case diagram A behavioral diagram that shows a set of use cases and actors and their relationships 4. Sequence diagram A behavioral diagram that shows an interaction, emphasizing the time ordering of messages 5. Collaboration diagram A behavioral diagram that shows an interaction, emphasizing the structural organization of the objects that send and receive messages 6. State chart diagram A behavioral diagram that shows a state machine, emphasizing the event-ordered behavior of an object 7. Activity diagram A behavioral diagram that shows a state machine, emphasizing the flow from activity to activity 8. Component diagram A structural diagram that shows a set of components and their relationships 9. Deployment diagram A structural diagram that shows a set of nodes and their relationships
5. 6. 1. Write the complete problem statement 2. Write the software requirement specification document 3. Draw the entity relationship diagram 4. Draw the data flow diagrams at level 0 and level 1 5. Draw use case diagram 6. Draw activity diagram of all use cases. 7. Draw state chart diagram of all use cases 8. Draw sequence diagram of all use cases 9. Draw collaboration diagram of all use cases 10. Assign objects in sequence diagram to classes and make class diagram .
6. 7. S. No. Na me of the P ro gr am D ate Si gnature & Date Re ma rks
7. 8. Experiment:- 1 AIM:- Smart health management for kids.. REQUIREMENTS: Hardware Interfaces Dual Core Processor (2.0 GHz), 2 GB RAM Screen resolution of at least 800 x 600 required for proper and complete viewing of screens. Higher resolution would not be a problem. Software Interfaces Windows 7 Word Pad or Microsoft Word or LibreOffice PROBLEM STATEMENT OF “SMART HEALTH MANAGEMENT FOR KIDS” In 2015 “PUBLIC HEALTH FOUNDATION OF INDIA” published a report “INDIA HEALTH REPORT: NUTRITION 2015” according to which 43% of Indian Kids are suffering from Malnutrition, Pneumonia, Diarrhoea, Anemia and Psychological diseases due to which the overall growth of kids will be affected.
8. 9. So, “ THE SMART HEALTH MANAGEMENT FOR KIDS” are developed to overcome this situation and predict to the growth and development of kids. In current scenario,the record of vaccination of kids are mention in register, so the proper data will not be stored and it is not easy to access the data from register. Register contain the normal information such as Name, Dob, and vaccination Record. So, from this record the advance health report can not be access due to which the prediction of health of kids is no poissible. Some issue in present health system are following :- · Missing of record. · Proper vaccination not be done on time. · Lack of nutritions,and care. · Lot of kids suffering from underweight, overweight and mentally disorder. · Prediction is not possible. · Access of data is not easier. · A lots of diseas are not track. · Needs of calories, protine, vitamins, and other essential nutrient depends upon the weight of the kid but due to not getting the proper nutrition the growth of the kids not achive as required. · The ratio of hight and weight not be maintain. To overcome all the situation which mention above “THE SMART HEALTH MANAGEMENT FOR KIDS” will be very effective and reduce the problem which mention above.
9. 10. Experiment:- 2 Aim: Understanding an SRS. Requirements: Hardware Requirements: PC with 2.0 gigahertz 2 GB Ram 500 gigabytes (GB) of available hard disk space Keyboard and Mouse (compatible pointing device). Software Requirements: Rational Rose, Windows 7 Theory: An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time.
10. 11. The SRS document itself states in precise and explicit language those functions and capabilities a software system (i.e., a software application, an e commerce Web site, and so on) must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. A well-designed, well-written SRS accomplishes four major goals:  It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language (versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.  It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and
11. 12. helps break down the problem into its component parts in an orderly fashion.  It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised  It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification. SRS are typically developed during the first stages of "Requirements Development," which is the initial product development phase in which information is gathered about what requirements are needed--and not. This information-gathering stage can include on-site visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed. SRS should address the following :- The basic issues that the SRS shall address are the following: a) Functionality. What is the software supposed to do? b) External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software? c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.?
12. 13. d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations? e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc. Characteristics of a good SRS An SRS should be:- a) Correct b) Unambiguous c) Complete d) Consistent e) Ranked for importance and/or stability f) Verifiable g) Modifiable h) Traceable Correct - This is like motherhood and apple pie. Of course you want the specification to be correct. No one writes a specification that they know is incorrect. We like to say - "Correct and Ever Correcting." The discipline is keeping the specification up to date when you find things that are not correct. Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Again, easier
13. 14. said than done. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix them. Complete - A simple judge of this is that is should be all that is needed by the software designers to create the software. Consistent - The SRS should be consistent within itself and consistent to its reference documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another. Ranked for Importance - Very often a new system has requirements that are really marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS. Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of my favorites is - "The system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds." Modifiable - Having the same requirement in more than one place may not be wrong - but tends to make the document not maintainable. Traceable - Often, this is not important in a non-politicized environment. However, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. Why do we need this requirement?
14. 15. A sample of basic SRS Outline 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definition, Acronyms, and Abbreviation 1.4. References 1.5. Overview 2. The Overall Description 2.1. Product perspective 2.1.1. System Interfaces 2.1.2.User Interfaces 2.1.3. Hardware Interfaces 2.1.4. Software Interfaces 2.1.5. Communication Interfaces 2.1.6. Memory Constraints 2.1.7. Operations 2.1.8. Site Adaptation Requirements 2.2. Product Functions 2.3. User Characteristics 2.4. Constraints 2.5. Assumptions and Dependencies
15. 16. 2.6. Apportioning and Requirements 3. Specific Requirements 3.1. External Interfaces Requirements 3.1.1. User Interfaces 3.1.2. Hardware Interfaces 3.1.3. Software Interfaces 3.1.4. Communications Interfaces 3.2. System Features 3.2.1. System Feature 1 3.2.1.1. Introduction of feature 3.2.1.2. Stimulus Sequence 3.2.1.3. Associated Functional Requirements 3.3. Performance Requirements 3.4. Design Constraints 3.5. Software System Attributes 3.6. Other Requirements
16. 17. SOFTWARE REQUIREMENTSSOFTWARE REQUIREMENTS SPECIFICATIONSPECIFICATION SMART HEALTH MANAGEMENT FOR KIDS
17. 18. 1. Introduction- “SMART HEALTH MANAGEMENT SYSTEM FOR KIDS ” are the health management system mainly focus on the overall care of kid from birth upto 5 years.It include the tracking of vaccination of the kids and their diets. The careing of kids is very difficult specially upto 5 year and kids also grow very fast during this period.The overall developement of the kids depend on care which will be provided during this time period. 1.1 Purpose- The purpose of this SRS is to describe the requirements involved in developing “SMART HEALTH MANAGEMENT SYSTEM FOR KIDS” (SHMSK). The intended audience is any parent who wants track the growth of his kids. And the doctors or goverement body who want to manage the record of the kids. 1.2 Scope- The product is titled “SMART HEALTH MANAGEMENT SYSTEM FOR KIDS” (SHMSK). This product will perform the following task:-  It allow the doctor/nurse to create the new entry for kids.  It allow the doctor/nurse to mentain the database of the kids.  It allow the doctor/nurse to update the information about the kids.  It allow parent to fatch the information of the kids.  It allow the goverment body to fatch the informaion regarding kids. 1.3 Definition, Acronyms, and Abbreviation-
18. 19. SHMSK:-“SMART HEALTH MANAGEMENT SYSTEM FOR KIDS” 1.4 References- IEEE standard 830-1998 recommended practice for Software Requirements Specifications-Description 1.5 Overview- The SRS contains an analysis of the requirements necessary to help easy design. The overall description provides interface requirements for the health management, product perspective, hardware interfaces, software interfaces, communication interface, memory constraints, product functions, user characteristics and other constraints. Succeeding pages illustrate the characteristics of typical naïve users accessing the system along with legal and functional constraints enforced that affect health management in any fashion. 2. The Overall Description- 2.1 Product perspective- 2.1.1 System Interfaces- The system must interface with the standard output device, keyboard and mouse to interact with this software. 2.1.2 User Interfaces- The system must interface with the standard output device, keyboard and mouse to interact with this software. 2.1.3 Hardware Interfaces- Hard disk: The database connectivity requires a hardware configuration that is on-line. This makes it necessary to have a fast database system (such as any RDBMS) running on high rpm hard-disk permitting complete data redundancy and backup systems to support the primary goal of reliability. 2.1.4 Software Interfaces- Back End: Jupyter notebook. Front End: Pycharm. 2.1.5 Communication Interfaces- The machine needs to communicate with the central database for each session for various functions such as login verification, database access etc. so the following are the various communication interface requirements that are needed to be fulfilled in order to run the software successfully:- The system will employ dial-up POS with the central server for low cost communication. The communication protocol used shall be TCP/IP. Protocol .used for data transfer shall be File Transfer Protocol.(FTP) 2.1.6 Memory Constraints- No specific constraints of memory. 2.1.7 Operations-
19. 20. The doctor/nurse can create an entering and they acn also performed the some operation such as Login, Update. The Parent can access the detail of his kids. They get the information regarding the kids health-care. 2.1.8 Site Adaptation Requirement- No specific requirement of a site. 2.2 Product Functions- During the Creation of new Id the following data should be provided to the doctor/nurse by the parent. 1.Creating a new ID:-  Kid’s Name  Kid’s Parent Name  Kid’s Date Of Birth  Kid’s weight  Kid’s hight  Kid’s address 2.Operating with created account:-  Parent can access the information.  Doctor/nurse can edit the information  Goverment body can access the record. 2.3 User Characteristics- The intended users of this software need not have specific knowledge as to what is the internal operation of the system. Thus the end user is at a high level of abstraction that allows easier, faster operation and reduces the knowledge requirement of end user. The Product is absolutely user friendly, so the intended users can be the naïve users. The product does not expect the user to possess any technical background. Any person who knows to use the mouse and the keyboard can successfully use this product. 2.4 Constraints- At the time of creating the new account, each user gives a Id number and is provided with a password that must be used for furthe login. Hence the user is required to remember or store these numbers carefully. At the time of creating the new Id date of Birth of kids must be less then 5 Years. 2.5 Assumptions and Dependencies- The requirements stated in the SRS could be affected by the following factors:- One major dependency that the update of information regarding kids will be on fixed interval of the so that the software will work properly . A delay in
20. 21. doing the same will result to tremendous loss for health of the kids. So this should be changed as and when required by the developer. Another constraint relating to the operating environment is that we are specific to Oracle Database 2.6 Apportioning of Requirements- Our development team is working on a health prediction so that the disease which may affected the health of the kids can be treated on first stage We will also working for prediction a diet accourding to height and weight ratio of the kids. All of these facility will be available at our next update. 3. Specific Requirements- 3.1 External Interfaces- 3.1.1. User Interfaces- Open Id Screen:- Various fields available on this screen will be:- -Enter Name -Enter Id -Enter Mob-No -Enter address Login Screen:- Fields available on this screen are:- -Login ID -Password Updation Info Screen:- Fields available on this screen are:- -Update vaccination -Update hight -update weight -View Info Fields available on this screen are:- -Change Password 3.1.2. Hardware Interfaces- None 3.1.3 Software Interfaces- -Any Windows based operating system. -MySql Server Database -Python, Html, Css 3.1.4 Communications Interfaces-
21. 22. None 3.2 System Features- 3.2.1 System Feature 1- 3.2.1.1 Introduction of feature- Validity check: JavaScript provides validity checks for various fields in the forms. Sequencing Information: All the information regarding Id details, Kids details, Vaccination Info etc should be handled. Error handling: If any of the validations or sequencing flows does not hold true then. Appropriate error messages will be prompted to the user for doing the needful. 3.2.1.2 Response Sequence- As user open his browser, browser have already fixed address. The dns server will map the domain to ip Address of the host server and a TCP connection is setup between user browser and the server. Then using HTTP protocol the server will send the homepage of health management system to the user browser and if Everything goes well, user see the home page. 3.2.1.3 Associated Functional Requirement- This section gives a functional requirement that applicable to the Online Health Management System for Kids. There three sub modules in this phase. 1. Parent module 2. Administrative module 3. Account Setting module 3.3 Performance Requirements – No specific Static and dynamic Numerical requirements are available. 3.4 Design Constraints- None. 3.5 Software System Attributes- 3.5.1 Reliability- The system should work reliably, with automatic backup and recovery features. In case of unexpected termination of a session, the unsaved data should be recovered without loss and displayed to the respective users for saving into the system or continuing with the work. 3.5.2 Availability- The entire system should be available round the year, except for a periodic maintenance. The maintenance period should be pre scheduled and short. The users should be reminded of the unavailability period, well in advance. 3.5.3 Security-
22. 23. The system, at any time, should be accessed only by the authenticated users. The system is required to end the session automatically, when an open session is not used for a specific period of time. 3.5.4 Maintainability- The document should be easy for the users who execute the system day to day, for the developers who wish to edit or develop further, and for the personnel who is in charge of the maintenance. The system should inform the main center automatically as soon as it detects any error. The kind of fault and the problem being encountered should also be mentioned by the system automatically. 3.5.5 Portability- The system should support new versions of the related browsers. The administrative and server technologies should be standard and supported by most platforms. 3.6 Other Requirements- None Experiment:- 3 AIM :- To draw a sample ENTITY RELATIONSHIP DIAGRAM for Automated Banking System. Hardware Requirements:- Dual Core processor (2.0 GHz), 2 GB RAM, Standard keyboard And mouse, colored monitor. Software Requirements:- Rational Rose, Windows 7, THEORY:- Entity Relationship Diagrams are a major data modeling tool and will help organize the data in your project into entities and define the relationships between the entities. This process has proved to enable the analyst to produce a good database structure so that the data can be stored and retrieved in a most efficient manner. Entity:-
23. 24. A data entity is anything real or abstract about which we want to store data. Entity types fall into five classes: roles, events, locations, tangible things or concepts. E.g. Parent, Doctor, Nurse, Vaccination. Specific examples of an entity are called instances. Relationship:- A data relationship is a natural association that exists between one or more entities. E.g. Kids and Doctor/Nurse. Cardinality defines the number of occurrences of one entity for a single occurrence of the related entity. Attribute:- A data attribute is a characteristic common to all or most instances of a particular entity. Synonyms include Kids, data element, field. E.g. Name, address, Id are all attributes of the entity Kids. An attribute or combination of attributes that uniquely identifies one and only one instance of an entity is called a primary key or identifier. E.g. Id is a primary key for Kids. AN ENTITY RE LATIONSHIP DIAGRAM METHODOLOGY: (One way of doing it) 1. Identify Entities Identify the roles, events, locations, tangible things or concepts about which the end-users want to store data. 2. Find Relationships Find the natural associations between pairs of entities using a relationship matrix. 3. Draw Rough ERD Put entities in rectangles and relationships on line segments connecting the entities. 4. Fill in Cardinality Determine the number of occurrences of one entity for a single occurrence of the related entity. 5. Define Primary Keys Identify the data attribute(s) that uniquely identify one and only one occurrence of each entity. 6. Draw Key-Based ERD Eliminate Many-to-Many relationships and include primary and foreign keys in each entity.
24. 25. 7. Identify Attributes Name the information details (fields) which are essential to the system under development. 8. Map Attributes For each attribute, match it with exactly one entity that it describes. Experiment:-4 AIM:- To prepare DATA FLOW DIAGRAM for any project. REQUIREMENTS:- Hardware Interfaces:- Dual Core Processor ( CPU 2.0 GHz), 2 GB RAM Screen resolution of at least 800 x 600 required for proper and complete viewing of screens. Higher resolution would not be a problem. Software Interfaces:- Windows 7 Word-pad or Microsoft Word
25. 26. THEORY: Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs. Experiment:-5 Aim :- Draw The Use Case Diagram using Rational Rose. Hardware Requirements:- Dual Core processor (2.0 GHz), 2 GB RAM, Standard keyboard and mouse, Colored monitor. Software Requirements:- Rational Rose, Windows 7,
26. 27. Theory:- According to the UML specification a use case diagram is “a diagram that shows the relationships among actors and use cases within a system.” Use case diagrams are often used to: • Provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model or a business model. • Communicate the scope of a development a project Model. • your analysis of your usage requirements in the form of a system use case model. Use case models should be developed from the point of view of your project stakeholders and not from the (often technical) point of view of developers. There are guidelines for: USE CASES:- A use case describes a sequence of actions that provide a measurable value to an actor. A use case is drawn as a horizontal ellipse on a UML use case diagram. 1. Use Case Names Begin With a Strong Verb 2. Name Use Cases Using Domain Terminology 3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram 4. Imply Timing Considerations By Stacking Use Cases. ACTOR:- An actor is a person, organization, or external system that plays a role in one or more interactions with your system (actors are typically drawn as stick figures on UML Use Case diagrams). 5. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram 6. Draw Actors To The Outside Of A Use Case Diagram 7. Name Actors With Singular, Business-Relevant Nouns 8. Associate Each Actor With One Or More Use Cases 9. Actors Model Roles, Not Positions 10.Use <<system>> to Indicate System Actors 11. Actors Don’t Interact With One Another 12. Introduce an Actor Called “Time” to Initiate Scheduled Events RELATIONSHIPS:-
27. 28. There are several types of relationships that may appear on a use case diagram:- • An association between an actor and a use case • An association between two use cases • A generalization between two actors • A generalization between two use cases Associations are depicted as lines connecting two modeling elements with an optional open-headed arrowhead on one end of the line indicating the direction of the initial invocation of the relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing towards the more general modeling element. SYSTEM BOUNDARY BOXES:- The rectangle around the use cases is called the system boundary box and as the name suggests it indicates the scope of your system – the use cases inside the rectangle represent the functionality that you intend to implement. 1. Indicate Release Scope with a System Boundary Box. 2. Avoid Meaningless System Boundary Boxes.
28. 29. Experiment:-6 AIM:- To draw a sample activity diagram for automated banking system. Hardware Requirements: Dual Core processor (2.0 GHz), 2 Gb RAM, Standard keyboard and mouse, colored monitor. Software Requirements: Rational Rose, Windows 7 THEORY:- UML 2 activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that you don’t require an activity diagram. In many ways UML activity diagrams are the object-oriented equivalent of flow charts and dataflow diagrams (DFDs) from structured development. Let’s start by describing the basic notation : • Initial node. The filled in circle is the starting point of the diagram. An initial node isn’t required although it does make it significantly easier to read the diagram. • Activity final node. The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes.
29. 30. • Activity. The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student Screen. • Flow/edge. The arrows on the diagram. Although there is a subtle difference between flows and edges, never a practical purpose for the difference although • Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity. • Join. A black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing. • Condition. Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in order to traverse the node. • Decision. A diamond with one flow entering and several leaving. The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious. • Merge. A diamond with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow. • Partition. If figure is organized into three partitions, it is also called swim lanes, indicating who/what is performing the activities (either the Applicant, Registrar, or System). • Sub-activity indicator. The rake in the bottom corner of an activity, such as in the Apply to University activity, indicates that the activity is described by a more finely detailed activity diagram. • Flow final. The circle with the X through it. This indicates that the process stops at this point.
30.  Experiment:-7 AIM:- To prepare STATE CHART DIAGRAM for “HEALTH MANAGEMENT SYSTEM FOR KIDS”. REQUIREMENTS:- Hardware Interfaces:- Dual Core Processor (CPU 2.0 GHz), 2 Gb RAM ,Screen resolution of at least 800 x 600 required for proper and complete viewing of screens. Higher resolution would not be a problem. Software Interfaces:- Windows 7 IBM Rational Rose Software THEORY:- • State Chart Diagrams provide a way to model the various states in which an object can exist. • There are two special states: the start state and the stop state. The Start state is represented by a block dot. • The Stop state is represented by a bull’s eye. • A condition enclosed in square brackets is called a guard condition, and controls when a transition can or cannot occur.
31.  • Processes that occur while an object is in certain state are called actions. Experiment:- 8 Aim:- Steps to draw the Sequence Diagram automated banking system. Hardware Requirements:- Dual Core processor (2.0 GHz),2 GB RAM, Standard keyboard and mouse, colored monitor. Software Requirements:- Rational Rose, Windows 7 Theory: UML sequence diagrams model the flow of logic within the system in a visual manner, enabling the user both to document and validate the logic, and are commonly used for both analysis and design purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling, which focuses on I dentifying the behavior within your system. Sequence diagrams, along with class diagrams and physical data models are the most important design- level models for modern application development. Sequence diagrams are typically used to model:- Usage scenarios:- A usage scenario is a description of a potential way the system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of
32. action, plus one or more alternate scenarios. The logic of a usage scenario may also be a pass through the logic contained in several use cases. For example, a Kids make an id and then immediately enrolls in three vaccenication. The logic of methods. Sequence diagrams can be used to explore the logic of a complex operation, function, or procedure. One way to think of sequence diagrams, particularly highly detailed diagrams, is as visual object code. The logic of services. A service is effectively a high-level method, often one that can be invoked by a wide variety of clients. Experiment:-9 Aim:- To draw the collaboration Diagram using Rational Rose. Hardware Requirements:- Dual Core Processor (2.0 GHz), 2 GB RAM, Standard keyboard and mouse, colored monitor. Software Requirements:- Rational Rose, Windows 7 THEORY:- Collaboration diagrams are also relatively easy to draw. They show the relationship Between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence numbers. As the name suggests, they show the sequence of the messages as they are passed between the objects. There are many acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be used, as the example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can because.
33. 34. Experiment:-10 Aim:- To draw the Class Diagram using Rational Rose. Hardware Requirements:- Dual Core processor (2.0 GHz), 2 GB RAM, Standard keyboard and mouse, colored monitor. Software Requirements:- Rational Rose, Windows 7 THEORY: A class diagram is a type of static structure diagram that describes the structure of a System by showing the system's classes, their attributes, and the relationships between the Classes. Class diagrams show the classes of the system, their inter-relationships, and the Operations and attributes of the classes. Class diagrams are typically used, although not all at once, to: • Explore domain concepts in the form of a domain model • Analyze requirements in the form of a conceptual/analysis model
34. • Depict the detailed design of object-oriented or object-based software A class model is comprised of one or more class diagrams and the supporting Specifications that describe model elements including classes, relationships between Classes, and interfaces. There are guidelines 1. General issues 2. Classes 3. Interfaces 4. Relationships 5. Inheritance 6. Aggregation and Composition GENERAL GUIDELINES:- Because class diagrams are used for a variety of purposes – from understanding Requirements to describing your detailed design – it is needed to apply a different style in Each circumstance. This section describes style guidelines pertaining to different types of Class diagrams. CLASSES:- A class in the software system is represented by a box with the name of the class written Inside it. A compartment below the class name can show the class's attributes (i.e. its Properties). Each attribute is shown with at least its name, and optionally with its type, Initial value, and other properties. A class is effectively a template from which objects are created (instantiated). Classes Define attributes, information that is pertinent to their instances, and operations, Functionality that the objects support. Classes will also realize interfaces (more on this Later). Class diagrams are widely used to describe the types of objects in a system and their Relationships. Class diagrams model class structure and contents using design elements Such as classes, packages and objects. Class diagrams describe three different Perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the Design. INTERFACES:- An interface is a collection of operation signature and/or attribute definitions that ideally Defines a cohesive set of behaviors. Interface a class or component must implement the Operations and attributes defined by the interface. Any given class or component may Implement zero or more
35. interfaces and one or more classes or components can implement The same interface. RELATIONSHIPS:- A relationship is a general term covering the specific types of logical connections found on a class and object diagram. Class diagrams also display relationships such as containment, inheritance, associations and others. The association relationship is the most common relationship in a class diagram. The Association shows the relationship between instances of classes. Another common relationship in class diagrams is a generalization. A generalization is used when two classes are similar, but have some differences. AGGREGATION:- Aggregation is a variant of the "has a" or association relationship; composition is more Specific than aggregation. Aggregation occurs when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container-- Essentially, if the container is destroyed, its contents are not. ASSOCIATION:- Association are semantic connection between classes. When an association connects two classes , each class can send messages to other in a sequence or a collaboration diagram . Associations can be bidirectional or unidirectional. DEPENDENCIES:- Dependencies connect two classes. Dependencies are always unidirectional and show that one class, depends on the definitions in another class