0% found this document useful (0 votes)
4 views6 pages

Understanding System Modeling and UML

The document outlines key concepts in system modeling, including definitions of systems, models, work products, activities, tasks, requirements, notations, methods, and methodologies. It emphasizes the importance of communication, rationale management, software configuration management, and project management in software development. Additionally, it introduces the Unified Modeling Language (UML) as a standard for visualizing system designs through various types of diagrams.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views6 pages

Understanding System Modeling and UML

The document outlines key concepts in system modeling, including definitions of systems, models, work products, activities, tasks, requirements, notations, methods, and methodologies. It emphasizes the importance of communication, rationale management, software configuration management, and project management in software development. Additionally, it introduces the Unified Modeling Language (UML) as a standard for visualizing system designs through various types of diagrams.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

1

 system means collection of interconnected parts.


 Modeling is a way to deal with complexity by ignoring irrelevant details.
 We use the term model to refer to any abstraction of the system.
 A TicketDistributor for an underground train is a system.
 Blueprints for the TicketDistributor, s
o chematics of its electrical wiring, and
o object models of its software are models of the TicketDistributor.
o The project schedule, its budget, and its planned deadlines are models of the development project.

 A work product is an artifact that is produced during the development, such as a document or a piece of software for other
developers or for the client.
 We refer to a work product for the project’s internal consumption as an internal work product.
 We refer to a work product that must be delivered to a client as a deliverable.
 Deliverables are generally defined prior to the start of the project and specified by a contract binding the developers with
the client.
Table 1-2 describes examples of work products for the TicketDistributor example.

An activity is a set of tasks that is performed toward a specific purpose. Activities are also sometimes called phases.
 For example, requirements elicitation is an activity whose purpose is to define with the client what the system will
do.
 Delivery is an activity whose purpose is to install the system at an operational location.
 Management is an activity whose purpose is to monitor and control the project such that it meets its goals (e.g.,
deadline, quality, budget).
 Activities can be composed of other activities.
2

o The delivery activity includes a software installation activity and an operator training activity. Activities
are also sometimes called phases.

A task represents an atomic unit of work that can be managed:


 A manager assigns it to a developer, the developer carries it out, and the manager monitors the progress and completion
of the task.
 Tasks consume resources, result in work products, and depend on work products produced by other tasks.
Resources are assets that are used to accomplish work.
 Resources include time, equipment, and labor.
 When planning a project, a manager breaks down the work into tasks and assigns them to resources.

Requirements specify a set of features that the system must have.


 A functional requirement is a specification of a function that the system must support,
o The user must be able to purchase tickets and The user must be able to access tariff information are
functional requirements.
 nonfunctional requirement is a constraint on the operation of the system that is not related directly to a function of
the system.
o The user must be provided feedback in less than one second and The colors used in the interface should be
consistent with the company colors are nonfunctional requirements.

A notation is a graphical or textual set of rules for representing a model.


 The Roman alphabet is a notation for representing words.
 UML (Unified Modeling Language [OMG, 2009]), the notation we use throughout this book, is a notation for representing
object-oriented models.
A method is a repeatable technique that specifies the steps involved in solving a specific problem.
 A recipe is a method for cooking a specific dish.
 A sorting algorithm is a method for ordering elements of a list.
3

A methodology is a collection of methods for solving a class of problems and specifies how and when each method should be used.
 A seafood cookbook with a collection of recipes is a methodology for preparing seafood if it also contains advice on how
ingredients should be used and what to do if not all ingredients are available.
 The Object Modeling Technique, the Booch methodology are object-oriented methodologies for developing software.

 the client and developers define the purpose of the system.

 result of this activity 


o actors  roles such as end users, other computers the system needs to deal with (e.g., a central bank computer, a
network), and the environment (e.g., a chemical process)
o use cases sequences of events that describe all the possible actions between an actor and the system for a given
piece of functionality.

analysis, 
 developers aim to produce a model of the system that is correct, complete, consistent, and unambiguous.
 Developers transform the use cases produced during requirements elicitation into an object model that completely describes
the system.
4

 developers define the design goals of the project


 decompose the system into smaller subsystems that can be realized by individual teams.
 Developers also select strategies for building the system 
o hardware/software platform
o data management strategy,
o the global control flow,
o the access control policy, and
o the handling of boundary conditions.

 developers define solution domain objects to bridge the gap between the analysis model and the hardware/software
platform defined during system design.
o interfaces,
o selecting off-the-shelf components,
o restructuring the object model to attain design goals such as extensibility or understandability, and optimizing the
object model for performance.
o The result of the object design activity is a detailed object model annotated with constraints and precise
descriptions for each element.

 developers translate the solution domain model into source code.


o implementing the attributes and methods of each object and
o integrating all the objects such that they function as a single system.

 unit testing
 integration testing,
 system testing

Management activities not only involve managers, but also most of the other project participants as well. Management activities include:
• Communication
• The most critical and time-consuming activity in software engineering.
• Misunderstandings and omissions often lead to faults and delays that are expensive to correct
5

• Communication includes the exchange of models and documents about the system and its application domain,
reporting the status of work products, providing feedback on the quality of work products, raising and
negotiating issues, and communicating decisions.
• SOLUTION: COMPUTER AIDED Software Engineering (CASE), USE CASE DOCUMENT ETC.
• Rationale Management
• Rationale is the justification of decisions.
• Deals with changes , need to be discussed, reviewed etc.
• Software Configuration Management
• is the process that monitors and controls changes in work products.
• enables developers to track changes.
• enables developers to control change.
• Project Management
• includes planning and budgeting the project during negotiations with the client,
• hiring developers and organizing them into teams,
• monitoring the status of the project, and intervening when deviations occur.
• Software Life Cycle
• Developers build models of the application and solution domains to deal with their complexity.
• The process of developing software can also be viewed as a complex system with inputs, outputs, activities, and
resources.

Chapter 2:Modeling with UML


 unified modeling language (UML) is a general-purpose visual modeling language that is intended
to provide a standard way to visualize the design of a system.
 UML provides a standard notation for many types of diagrams which can be roughly divided into
three main groups: behavior diagrams, interaction diagrams, and structure diagrams.

System development focuses on three different models of the system (see Figure 1-2):
• The functional model, represented in UML with use case diagrams, describes the functionality of the
system from the user’s point of view.
• The object model, represented in UML with class diagrams, describes the structure of the
system in terms of objects, attributes, associations, and operations.
• The dynamic model, represented in UML with interaction diagrams, state machine diagrams,
and activity diagrams, describes the internal behavior of the system.

Five UML notations:


• Use Case Diagrams (Section 2.2.1)
• Class Diagrams (Section 2.2.2)
• Interaction Diagrams (Section 2.2.3)
• State Machine Diagrams (Section 2.2.4)
• Activity Diagrams (Section 2.2.5).
6

 Class diagrams describe the system in terms of objects, classes, attributes, operations, and their associations.
 class diagram describing the elements of all the watches of the SimpleWatch class.
o These watch objects all have an association to
 an object of the PushButton class,
 an object of the Display class,
 an object of the Time class, and
 an object of the Battery class.
 The numbers on the ends of associations denote the number of links each SimpleWatch object can have
with an object of a given class.

You might also like