In their 1999 book The Unified Software Development Process , the authors of Uni
ID: 3850826 • Letter: I
Question
In their 1999 book The Unified Software Development Process, the authors of Unified Modeling Language (UML) noted that any modern object-oriented approach to developing information systems must be use-case driven, architecture-centric, and iterative and incremental. Using your preferred UML drawing tool, draw your responses visually. Use any shapes you think are appropriate for your diagrams. Draw a diagram depicting the three basic properties of the modern software development processes. Draw another diagram depicting the models produced by these processes. Links to UML drawing tools:
Specifically, the following critical elements must be addressed:
Explanation / Answer
Three basic properties of modern software development process are:
1. It must be use case driven.In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system, to achieve a goal. The actor can be a human or other external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements.
Use case analysis is an important and valuable requirement analysis technique that has been widely used in modern software engineering.One of the key aspects of the Unified Process is its use of use cases as a driving force for development. The phrase use case driven refers to the fact that the project team uses the use cases to drive all development work, from initial gathering and negotiation of requirements through code.Use cases are highly suitable for capturing requirements and for driving analysis, design, and implementation for several reasons.
Use cases are expressed from the perspective of the system's users, which translates into a higher comfort level for customers, as they can see themselves reflected in the use case text. It's relatively difficult for a customer to see himself or herself in the context of requirements text.
Use cases are expressed in natural language (English or the native language of the customers). Well-written use cases are also intuitively obvious to the reader.
Use cases offer a considerably greater ability for everyone to understand the real requirements on the system than typical requirements documents, which tend to contain a lot of ambiguous, redundant, and contradictory text. Ideally, the stakeholders should regard use cases as binding contracts between customers and developers, with all parties agreeing on the system that will be built.
Use cases offer the ability to achieve a high degree of traceability of requirements into the models that result from ongoing development. By keeping the use cases close by at all times, the development team is always in touch with the customers' requirements.
Use cases offer a simple way to decompose the requirements into chunks that allow for allocation of work to subteams and also facilitate project management. This is not the same as functional decomposition.
2. Architecture centric :
In the context of software, the term architecture has different meanings depending on whom you ask. The definition in UML Explained is as follows:
The fundamental organization of the system as a whole. Aspects of an architecture include static elements, dynamic elements, how those elements work together, and the overall architectural style that guides the organization of the system. Architecture also addresses issues such as performance, scalability, reuse, and economic and technological constraints.
The Unified Process specifies that the architecture of the system being built, as the fundamental foundation on which that system will rest, must sit at the heart of the project team's efforts to shape the system, and also that architecture, in conjunction with the use cases, must drive the exploration of all aspects of the system. You might think of the architecture as expressing the common vision that all members of the team must share in order for the resulting system to be suitably robust, flexible, expandable, and cost-effective.
In the context of the process, architecture is primarily specified in terms of views of six models. (See "The Five Workflows" later in this chapter for brief descriptions of these models.) These views reflect the "architecturally significant" elements of those models; taken together, the views form the architecture description. The project team initializes the architecture description early, then expands and refines it during virtually all the activities of the project.
The following subsections discuss the key reasons why architecture is so important to the Unified Process.
Understanding the Big Picture
The tools and techniques available to developers for building software are growing increasingly powerful. For better or worse, though, software itself, especially with its new focus on distributed computing, is getting considerably more complex as well, and there aren't any indications that the tools and techniques will "catch up" any time soon. Also, customers' attention spans are becoming shorter and shorter as their demands on development teams grow more sophisticated. The result is that it's very difficult for all but a few especially gifted people to understand—really understand—most software systems to any meaningful extent. The architecture description is meant, first and foremost, to facilitate an understanding of the architecture of the system being built. Rigorous modeling, and careful attention to the readability of the associated UML diagrams and supporting text, will go a long way toward turning the architecture description into the fulcrum for increased understanding of the "big picture" of the new system.
Organizing the Development Effort
A sound architecture explicitly defines discrete chunks of the system, as well as the interfaces among the various parts of the system. It also makes effective use of one or more architectural patterns, which help shape the development effort on various levels. (Client/server, three-tier, and N-tier are all examples of well-known architectural patterns. Other patterns focus on things like object request brokers [ORBs], which sit at the center of systems that use distributed components, and virtual machines, such as the one on top of which Java runs.) By using this aspect of architecture effectively, the project team can increase the chances that communication across subteams will add value to the effort.
Facilitating the Possibilities for Reuse
One of the key tenets of component-based development (CBD) is the idea that components should be usable, with a relative minimum of customization, in a variety of contexts. A well-constructed software architecture offers solid "scaffolding" on which components can reside and work gracefully with each other, while making it easy for teams building other systems to identify opportunities for possible reuse of any or all of those components. The bottom line is that the less time a team has to spend focusing on building new components, the more time it can spend on understanding the customers' problems and modeling the solutions.
Evolving the System
Maintaining and enhancing a system tends to occupy more time over the life of that system than it took to build it in the first place. When development projects find themselves operating in mythical "Internet time," with technologies evolving faster and business models changing more frequently than ever before, there's no question that a system of any size and complexity will be subject to evolutionary changes of a healthy magnitude. Having a solid architecture in place offers a set of essential reference points on which future development work can rely. An architecture that's been built such that changes in one part of the system almost never have adverse effects on other parts of the system also greatly enhances team members' ability to evolve the system effectively and efficiently.
Guiding the Use Cases
In one sense, use cases drive the architecture of a software system, since the use cases do drive all of the development effort. In another sense, however, the architecture guides the selection and exploration of use cases. Decisions that architects must make about things like middleware, system software, legacy systems, and so forth, have a strong influence on the choice of which use cases the team focuses on at what point in the project. The basic idea, then, is to focus on those use cases that will add value to the architecture, which in turn helps shape the content of those use cases and the nature of the work involved in developing the system from them.
Iterative and Incremental
The third fundamental tenet of the Unified Process is its iterative and incremental nature. An iteration is a mini-project that results in a version of the system that will be released internally or externally. This version is supposed to offer incremental improvement over the previous version, which is why the result of an iteration is called an increment.