Download
1 / 33
330 likes | 470 Views
Introduction to Unified Modelling Language. Tujuan. Mengetahui latar belakang terbentuknya UML Mengetahui tentang Unified Process ( UP). Definisi.
E N D
Tujuan • Mengetahuilatarbelakangterbentuknya UML • Mengetahuitentang Unified Process (UP)
Definisi A language for specifiying, constructing, visualizing, and documenting the artifacts of a software-intensive system for Business Modelling and other non-software systems
Things : Structural • Define the static part of the model. • Represents physical and conceptual elements. • Including : • Class • Interface • Collaboration : a collection of UML building blocks • Use case : a set of actions represents by a system • Component : physical part of a system • Node : a physical element that exist at run-time & represents a computational resource (typically, hardware resources)
Things : Behavioural • Consists of the dynamic parts of UML models. • Include : • Interaction : messages exchanged among objects • State machine : sequence of states of an object during its lifetime
Things : Grouping • Grouping elements of UML models together. • Include : • Package : conceptual grouping of the systems
Things : Annotational • A mechanism to capture remarks, descriptions, and comments of UML model elements • Include : • Note
Relationship • Shows how elements are associated with each other. • Describe the functionality of an application.
Unified Process • Definition : The unified process provides a disciplined approach to assigning tasks and responsibilities within a development organization, to ensure production of a high-quality software product that meets the needs of its end users within a predictable schedule and budget.
Manage Requirements • Describes how to elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions; and easily capture and communicate business requirements
Develop Iteratively • Given today’s sophisticated software systems, it is not possible to sequentially first define the entire problem, design the entire solution, build the software and then test the product at the end. • An iterative approach is required that allows an increasing understanding of the problem through successive refinements, and to incrementally grow an effective solution over multiple iterations.
Visually Model Software • The process shows you how to visually model software to capture the structure and behavior of architectures and components. • This allows you to hide the details and write code using “graphical building blocks.” • Visual abstractions help you communicate different aspects of your software; see how the elements of the system fit together; make sure that the building blocks are consistent with your code; maintain consistency between a design and its implementation; and promote unambiguous communication
Verify Software Quality • Quality should be reviewed with respect to the requirements based on reliability, functionality, application performance and system performance. • Quality assessment is built into the process, in all activities, involving all participants, using objective measurements and criteria, and not treated as an afterthought or a separate activity performed by a separate group.
Use Component-based Architecture • It describes how to design a resilient architecture that is flexible, accommodates change, is intuitively understandable, and promotes more effective software reuse. • Components are non-trivial modules, subsystems that fulfill a clear function.
Control Changes to Software • The ability to manage change is making certain that each change is acceptable, and being able to track changes is essential in an environment in which change is inevitable. • The process describes how to control, track and monitor changes to enable successful iterative development.
UP Axioms • Use-case and risk driven • Architecture centric • Iterative and incremental • Supports object oriented techniques • A configurable process • Encourages ongoing quality control and risk management
Fase 1 : Inception • Define the scope of the project and develop business case • Goal: Get the project of the ground • The goal is to achieve concurrence among all stakeholders on the lifecycle objectives for the project. • To get the project of the ground • The primary objectives of the inception phase include: • Establishing feasibility • Creating a business case • Capturing essential requirements • Identifying critical risks • Estimating the overall cost and schedule for the entire project • Focus on requirements and analysis • Milestone: Life cycle objectives
Fase 2 : Elaboration • Plan project, specify features, and baseline the architecture • Goals: • Create an executable architectural baseline • Refine the risk assessment • Capture use cases to 80% of the functional requirements • Create a detailed plan for the construction phase • Milestone: Life cycle architecture
Fase 3 : Construction • Build the product • Goals: • To complete all requirements, analysis and design into a final system. • Focus: • Requirements • Uncover missed requirements • Analysis • Finish the analysis model • Design • Finish the design model • Implementation • Build the initial operational capability • Test • Milestone: Initial Operational Capability
Fase 4 : Transition • Transition the product to its users • Starts when beta testing is completed and the system is deployed • Goals: • Correct defects • Tailor the software to operate at the user site • Create manuals • Milestone: product release
References • http://www.sa-depot.com • Rational Company. Rational Unified Process : Best Practices for Software Development Teams. • Dennis, Alan, et.al. System Analysis and Design with UML Version 2.0. John Wiley & Sons, Inc.
