1.
Use Case Diagrams
These are the use case diagrams for the Bygone Cars specification. The UML use case diagrams describe the interaction of the person and its department with the system under design. Use cases are developed in collaborations between software developers and other project, such as users of the proposed system, who will not go on to perform the actual coding.
2. Use Case Descriptions
Use Case: Sales Office
Use Case: Sales Office
Use case: Warehouse
Use Case: Transport and Dispatch Department
3.
Collaboration Diagrams
These are the Collaboration Diagrams. UML Collaboration diagrams illustrate the relationship and interaction between the objects. The collaboration diagram illustrates messages being sent between classes and objects. A diagram is created for each system operation that relates to the current development cycle.
4.
Sequence ...
This is a preview of the whole essay
3.
Collaboration Diagrams
These are the Collaboration Diagrams. UML Collaboration diagrams illustrate the relationship and interaction between the objects. The collaboration diagram illustrates messages being sent between classes and objects. A diagram is created for each system operation that relates to the current development cycle.
4.
Sequence Diagrams
These are the sequence diagrams. The UML sequence diagrams are used to represent or model the flow of messages, events and actions between the objects the system.
5.
Class Diagram
This is a class diagram for the Bygone Cars specification. The show the classes of the system, their inter-relationships, and the operations and attributes of the classes.
6.
One of the main principles in the Object Oriented Approach is abstraction, not the data structures and processes separately but both together. An object is a set of data structures and the methods or operations needed to access those structures. Encapsulation of data structures and methods means that only the methods associated with the object can access the internal data structures. An object is a packaged item of information including the processes which manipulates it. The objects in Object Oriented software are reusable these are components which may often be used in different applications. In Object Oriented environments object libraries may be available for the programmer to build into solutions.
The key ideas of the object oriented approach are:
- Objects
- Encapsulation
- Class and Inheritance
- Instances and Instantiation
- Methods and Messages
Advantages and Disadvantages
Iteration
The iteration cycles and phases have the following characteristics;
Each iteration cycle consists of two support machines which are; the management and support and six development components which are; requirements, analysis, design, implementation, validation and deployment, these result in a product free.
- The management phase involves managing of the overall iteration cycle.
- The support phase involves supporting the needs and requirements of the stakeholders participating in the iteration cycle; this includes development environment support and configuration, standards definition and guidelines.
Within the construction development phase, iterations phases apply to the following;
- The requirements phase involves understanding or elaborating the requirements the problem imposes on its solution so that the problem can be elaborated and the solution can be specified.
- The analysis phase involves elaborating the solution specification. This phase hinges on the application knowledge.
- The design phase involves updating the foundation for the general solution and the foundation required to support the specific solution for the iteration cycle requirements. This phase hinges on the application of the knowledge.
- The implementation phase involves generating the solution for the iteration cycle’s needs.
- The deployment phase involves providing and integrating or delivering the solution or a subset of thereof.
Problems & Solutions
Problems and its solutions occur within a context. The problem of the system must be understood in order to be solved. The solution of the system to a problem must be understood in order to be constructed and used. The solution must be organized in order to help its understanding and hold fast to the various constraints of the context in which it will be realized. To solve the problem, suitable facts about the problem and solution must be captured and controlled around decisions regarding the problem and solution and depicted diagrams using some language that enables it to be communicated and leveraged in the problem-solving process.
Life Cycle
The life cycle is a common methodology for system development in a lot of organizations, featuring numerous phases that stain the progress of the systems analysis and design effort. The life cycle represents activities that must be done, and the phases are a way to introduce, in an organized way, the methods, techniques, tools, and skills necessary for successful systems analysis and design.
The life cycle approaches to state modelling are as follows:-
- Identify major system actions.
- Identify each class that is likely to have a state dependent response to these events.
- For each of these classes produce a first-cut state chart by considering the typical life cycle of an instance of the class.
- Examine the state chart and elaborate to encompass more detailed event behaviour.
- Enhance the state chart to include alternative scenarios.
- Review the state chart to ensure that is consistent with the use cases. In particular, check that the constraints that the state chart implies are appropriate.
- Iterate through steps 4, 5 and 6 until the state chart captures the necessary level of detail.
- Ensure consistency class diagram and interaction diagrams and other state charts
The life cycle approach is less official than the behavioural approach in its initial identification of events and related classes. It is often helpful to use a mixture of the two, since each provides checks on the other.
Traditional Life Cycle
The traditional life cycle had the property of locking in users to requirements that had been beforehand determined, even though those requirements might have been changed. The traditional life cycle is frequently used in that it tends to focus too little time on good analysis and design. The result is a system that does not match the user’s needs and one that requires extensive maintenance, unnecessary increasing development costs.
A view of the traditional life cycle in a diagrammatic view for information systems development is shown below.
The next phase in this model must begin after the previous phase is over. The Traditional Waterfall Life Cycle Model software model may be applicable to projects where:
- Software requirements are clearly defined and known
- Software development technologies and tools are well known
- New version of the existing software system is created
The entity phases of the Traditional Waterfall Life Cycle model are described more in detail below.
System Engineering
The System Engineering is an information system that involves human, software and hardware elements. This is the first stage of an information system’s project to recognize the major needs for the whole system and then to recognize those parts of the system that are the fines implemented in its software. This phase produces a high-level arrangement that defines how the main parts of the system will cooperate with each other.
Requirements Analysis
A Requirements Analysis is a description of the behaviour of the system that is to be developed. All the systems requirements need to be defined clearly. It includes a set of functional requirements that describes all the interactions the users will have with the software. If the project is worried with the development of elements that will be implemented in the software then these are the main focus of the requirements analysis.
Design
Once the system knows what they want from it, the design process can precede in problem solving and planning for the system. The design stage involves in getting a steadiness between requirements that conflict with each other, for example; maintainability and performance within the system.
Construction
The design phase is translated into the programme code. The structure may make use of different programming languages and database management systems for dissimilar parts of the system.
Testing
The system is tested to make sure that it satisfies the user’s needs perfectly and completely. Many levels of testing are performed. Individual mechanism are tested alone then are tested together as a sub system and then the sub systems are tested jointly as a complete system.
Installation
Once the system has been tested satisfactory it is delivered to the customer and installed for use. The introduction of the system has to be managed carefully so as not to cause unnecessary distribution and to minimize the attendant risk of change. For example, the approach is to run both the old and new systems in parallel to ensure that the new system operates effectively before discontinuing the operation of the old system.
Maintenance
It is most likely that the system will be a topic to change throughout its operating life. The delivered system may have received some corrections, and definite aspects of the system’s performance may not have been entirely implemented because of price or time constraints, but are then finished during this phase the maintenance.
Life cycle deliverables
Advantages and Disadvantages of Life Cycle Model
References
Object Oriented Systems Development
Ali Bahrami
McGraw-Hill Book Co – Singapore 1999
Priestley Mark, (2003 Second Edition), Practical Object-Oriented Design with UML
Booch, G.; Rumbaugh, J. and Jacobson, I. (1999 or Latest Edition): The Unified Modeling Language User Guide. Addison-Wesley, ISBN 0201 571684
- Booch, G.; Rumbaugh, J. and Jacobson, I. (1999 or Latest Edition): The Unified Modeling Language User Guide. Addison-Wesley, ISBN 0201 571684 or Latest.
- Bennett, S.; McRobb, S. and Farmer, R. (2002): Object-Oriented Systems Analysis and Design, Using UML. McGraw Hill, Second Edition, ISBN 0-07 70986-1.
- Sinan Si Alhir (1998 or Latest Edition): UML in a Nutshell. O’Reilly and Associates, ISBN 1-56592-448-7 or Latest.
- Fowler, M. & Scott, K. (1999): UML Distilled; Applying the Standard Object Modeling Language
- Martin, J. & Odell, J. (1998 or later): Object Oriented Methods; A Foundation.
- Whiteley David (2004) Palgrave Introduction to Information Systems.
- Priestley Mar, (2003 Second Edition), Practical Object-Oriented Design with UML
The Unified Modeling Language User Guide
Second Edition
Grady Booch
James Rumbaugh
Ivar Jacobson
Upper Saddle River
2005
| Page